Re: [PATCH 4/4] eeprom: at24: Add OF device ID table

[Javier Martinez Canillas]

Hello Andy,

On 03/14/2017 07:59 PM, Andy Shevchenko wrote:
> On Tue, Mar 14, 2017 at 5:16 PM, Javier Martinez Canillas
> <javier@xxxxxxxxxxxxxxx> wrote:
>> The driver doesn't have a struct of_device_id table but supported devices
>> are registered via Device Trees. This is working on the assumption that a
>> I2C device registered via OF will always match a legacy I2C device ID and
>> that the MODALIAS reported will always be of the form i2c:<device>.
>>
>> But this could change in the future so the correct approach is to have an
>> OF device ID table if the devices are registered via OF.
> 
> I'm bot sure this patch does something useful right now. Can we
> survive without it? I think we may.
> 

Yes, we can survive without it for now. But the problem is that with current
I2C core, DT-only I2C drivers must have an I2C device table in order to have
module auto-load working. That's because the core always reports as modalias
i2c:<foo> regardless if the device was registered via DT or legacy mechanism.

And some maintainers don't accept patches doing this duplication and instead
ask for the core to be fixed, i.e [0]. But to make sure that fixing the core
won't add regressions in drivers that are relying in the current behavior,
patches like $SUBJECT are needed.

So there isn't an agreement if is better to just rely in the current behavior
(and have a superfluous I2C device ID table) or fix the I2C core (and need a
OF device ID table). I personally prefer the latter since that means that an
DT-only driver will only need a OF table, and only drivers that supports both
will need both tables.

>>  drivers/misc/eeprom/at24.c | 189 ++++++++++++++++++++++++++++++++++++++++++++-
>>  1 file changed, 188 insertions(+), 1 deletion(-)
> 
> It's a huge! It will increase not only driver code base but memory
> footprint for almost no benefit.
>

Indeed, but these all are compatible strings used by DTS in mainline and so
should be in the OF device ID table in order to be matched and the proper
modalias reported (once the I2C core is fixed).

One option is to add #ifdef CONFIG_OF guards for the OF device table definition
but again there's no agreement on that one since some maintainers say the it is
better to always build the OF ID table than having #ifdefery in C code...

[0]: https://www.mail-archive.com/linux-kernel@xxxxxxxxxxxxxxx/msg1321026.html

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America