| Message ID | 20170523133448.4794-6-javier@dowhile0.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hello, On Tue, May 23, 2017 at 03:34:33PM +0200, Javier Martinez Canillas wrote: > The at24 driver allows to register I2C EEPROM chips using different vendor > and devices, but the I2C subsystem does not take the vendor into account > when matching using the I2C table since it only has device entries. > > But when matching using an OF table, both the vendor and device has to be > taken into account so the driver defines only a set of compatible strings > using the "atmel" vendor as a generic fallback for compatible I2C devices. > > So add this generic fallback to the device node compatible string to make > the device to match the driver using the OF device ID table. > > Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org> Assuming the of-table patch is accepted this can have my: Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Otherwise I'm not convinced this is worth the churn. Thanks Uwe
Hello Uwe, On Thu, May 25, 2017 at 8:29 PM, Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote: > Hello, > > On Tue, May 23, 2017 at 03:34:33PM +0200, Javier Martinez Canillas wrote: >> The at24 driver allows to register I2C EEPROM chips using different vendor >> and devices, but the I2C subsystem does not take the vendor into account >> when matching using the I2C table since it only has device entries. >> >> But when matching using an OF table, both the vendor and device has to be >> taken into account so the driver defines only a set of compatible strings >> using the "atmel" vendor as a generic fallback for compatible I2C devices. >> >> So add this generic fallback to the device node compatible string to make >> the device to match the driver using the OF device ID table. >> >> Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org> > > Assuming the of-table patch is accepted this can have my: > > Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> > Thanks a lot for the Ack. > Otherwise I'm not convinced this is worth the churn. > Both changes are needed in order to make sure that the driver and DTS won't regress when the I2C core is modified to report a proper MODALIAS for I2C devices registered via OF. > Thanks > Uwe > Best regards, Javier
diff --git a/arch/arm/boot/dts/efm32gg-dk3750.dts b/arch/arm/boot/dts/efm32gg-dk3750.dts index 98fc667d22c7..84f0a9abc290 100644 --- a/arch/arm/boot/dts/efm32gg-dk3750.dts +++ b/arch/arm/boot/dts/efm32gg-dk3750.dts @@ -36,7 +36,7 @@ }; eeprom@50 { - compatible = "microchip,24c02"; + compatible = "microchip,24c02", "atmel,24c02"; reg = <0x50>; pagesize = <16>; };
The at24 driver allows to register I2C EEPROM chips using different vendor and devices, but the I2C subsystem does not take the vendor into account when matching using the I2C table since it only has device entries. But when matching using an OF table, both the vendor and device has to be taken into account so the driver defines only a set of compatible strings using the "atmel" vendor as a generic fallback for compatible I2C devices. So add this generic fallback to the device node compatible string to make the device to match the driver using the OF device ID table. Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org> --- Changes in v5: - Only replace atmel variant but keep other EEPROM vendors (Geert Uytterhoeven). Changes in v4: - Only use the atmel manufacturer in the compatible string instead of keeping the deprecated ones (Rob Herring). Changes in v3: None Changes in v2: None arch/arm/boot/dts/efm32gg-dk3750.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)