Re: [PATCH 00/13] rtc: Add OF device table to I2C drivers that are missing it

[Alexandre Belloni]

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