On 03/03/2017 at 12:27:23 -0300, Javier Martinez Canillas wrote: > On 03/03/2017 12:01 PM, Alexandre Belloni wrote: > > On 03/03/2017 at 11:29:11 -0300, Javier Martinez Canillas wrote: > >> This series add OF device ID tables to RTC I2C drivers whose devices are > >> either used in Device Tree source files or are listed in binding docs as > >> a compatible string. > >> > >> That's done because the plan is to change the I2C core to report proper OF > >> modaliases instead of always reporting a MODALIAS=i2c:<foo> regardless if > >> a device was registered via DT or using the legacy platform data. > >> > > > > Doesn't that break the DT ABI for all i2c devices? A lot of people are > > getting the vendor wrong in the compatible string and because the i2c > > core doesn't care, the driver is still probed. Dropping that will break > > all those DTBs. > > Or will that only affect module autoload? > > > > The change will only be for module autoload. The I2C core will still attempt > to match the I2C device ID table as a fallback if fails to match the OF one. > So there's no change in the match logic for drivers that do the wrong thing. >
I'm probably not seeing the big picture here but then I don't understand why you are reworking the id->driver_data handling and using of_device_get_match_data instead. If this is related to b8a1a4cd5a98a2adf8dfd6902cd98e57d910ee12, that is a completely different issue (and that is probably the kind of changes that should be notified to maintainers). > If someone is using a wrong vendor prefix and the DT can't be changed, then > an entry in the OF device ID table has to be added for "wrong_vendor,device" > so the MODALIAS uevent can be "of:N*T*wrong_vendor,device". > And then, we end up with a crap load of useless strings that are matched against at boottime... I'm saying that because all the rv3029 compatible strings are wrong. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com