| Message ID | 20170523133448.4794-13-javier@dowhile0.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi. 2017-05-23 22:34 GMT+09:00 Javier Martinez Canillas <javier@dowhile0.org>: > 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/uniphier-pro4-ace.dts | 2 +- > arch/arm/boot/dts/uniphier-pro4-sanji.dts | 2 +- > arch/arm/boot/dts/uniphier-pxs2-gentil.dts | 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) Why didn't you touch arch/arm/boot/dts/uniphier-ref-daughter.dtsi ? BTW, has the driver change merged?
Hello Masahiro, On Mon, Jun 5, 2017 at 7:13 AM, Masahiro Yamada <yamada.masahiro@socionext.com> wrote: > Hi. > > 2017-05-23 22:34 GMT+09:00 Javier Martinez Canillas <javier@dowhile0.org>: >> 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/uniphier-pro4-ace.dts | 2 +- >> arch/arm/boot/dts/uniphier-pro4-sanji.dts | 2 +- >> arch/arm/boot/dts/uniphier-pxs2-gentil.dts | 2 +- >> 3 files changed, 3 insertions(+), 3 deletions(-) > > > Why didn't you touch > arch/arm/boot/dts/uniphier-ref-daughter.dtsi ? > Because the compatible string "microchip,24lc128" used by the I2C EEPROM node on that DTS is not supported by the drivers/misc/eeprom/at24.c driver (in fact the only occurrence for 24lc128 I see is in that DTS). Maybe is a typo and it should be "microchip,24c128" instead ? In any case, I think this should be fixed as a separate patch and is out of scope for this series. > > > BTW, has the driver change merged? > No, it hasn't been merged yet but there's no strict order in which the changes should be picked so the DTS patches can be applied independently. I haven't had feedback from Wolfram yet, but he was the one who suggested this and so I guess he will be Ok with the driver changes. > > > -- > Best Regards > Masahiro Yamada Best regards, Javier
Hi Javier, 2017-06-06 18:04 GMT+09:00 Javier Martinez Canillas <javier@dowhile0.org>: > Hello Masahiro, > > On Mon, Jun 5, 2017 at 7:13 AM, Masahiro Yamada > <yamada.masahiro@socionext.com> wrote: >> Hi. >> >> 2017-05-23 22:34 GMT+09:00 Javier Martinez Canillas <javier@dowhile0.org>: >>> 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/uniphier-pro4-ace.dts | 2 +- >>> arch/arm/boot/dts/uniphier-pro4-sanji.dts | 2 +- >>> arch/arm/boot/dts/uniphier-pxs2-gentil.dts | 2 +- >>> 3 files changed, 3 insertions(+), 3 deletions(-) >> >> >> Why didn't you touch >> arch/arm/boot/dts/uniphier-ref-daughter.dtsi ? >> > > Because the compatible string "microchip,24lc128" used by the I2C > EEPROM node on that DTS is not supported by the > drivers/misc/eeprom/at24.c driver (in fact the only occurrence for > 24lc128 I see is in that DTS). > > Maybe is a typo and it should be "microchip,24c128" instead ? I do not think so. I consulted a board developer. I also see 24LC128 on Microchip web site: http://www.microchip.com/wwwproducts/en/24LC128
Hello Masahiro, On Wed, Jun 7, 2017 at 3:10 AM, Masahiro Yamada <yamada.masahiro@socionext.com> wrote: [snip] >>> >>> Why didn't you touch >>> arch/arm/boot/dts/uniphier-ref-daughter.dtsi ? >>> >> >> Because the compatible string "microchip,24lc128" used by the I2C >> EEPROM node on that DTS is not supported by the >> drivers/misc/eeprom/at24.c driver (in fact the only occurrence for >> 24lc128 I see is in that DTS). >> >> Maybe is a typo and it should be "microchip,24c128" instead ? > > I do not think so. > I consulted a board developer. > > I also see 24LC128 on Microchip web site: > http://www.microchip.com/wwwproducts/en/24LC128 > Ah Ok, it was just a wild guess I did since the at24 driver didn't have support for this chip variant. My point stands though, this is an unrelated change to the goal of this patch-series and should be fixed separately. Best regards, Javier
2017-06-07 21:42 GMT+09:00 Javier Martinez Canillas <javier@dowhile0.org>: > Hello Masahiro, > > On Wed, Jun 7, 2017 at 3:10 AM, Masahiro Yamada > <yamada.masahiro@socionext.com> wrote: > > [snip] > >>>> >>>> Why didn't you touch >>>> arch/arm/boot/dts/uniphier-ref-daughter.dtsi ? >>>> >>> >>> Because the compatible string "microchip,24lc128" used by the I2C >>> EEPROM node on that DTS is not supported by the >>> drivers/misc/eeprom/at24.c driver (in fact the only occurrence for >>> 24lc128 I see is in that DTS). >>> >>> Maybe is a typo and it should be "microchip,24c128" instead ? >> >> I do not think so. >> I consulted a board developer. >> >> I also see 24LC128 on Microchip web site: >> http://www.microchip.com/wwwproducts/en/24LC128 >> > > Ah Ok, it was just a wild guess I did since the at24 driver didn't > have support for this chip variant. > My point stands though, this is an unrelated change to the goal of > this patch-series and should be fixed separately. > > Best regards, > Javier Applied to linux-uniphier. Thanks!
diff --git a/arch/arm/boot/dts/uniphier-pro4-ace.dts b/arch/arm/boot/dts/uniphier-pro4-ace.dts index fefc89149234..b9a4919d7c93 100644 --- a/arch/arm/boot/dts/uniphier-pro4-ace.dts +++ b/arch/arm/boot/dts/uniphier-pro4-ace.dts @@ -88,7 +88,7 @@ status = "okay"; eeprom@54 { - compatible = "st,24c64"; + compatible = "st,24c64", "atmel,24c64"; reg = <0x54>; pagesize = <32>; }; diff --git a/arch/arm/boot/dts/uniphier-pro4-sanji.dts b/arch/arm/boot/dts/uniphier-pro4-sanji.dts index 6c63c8bad825..3950baa8d55d 100644 --- a/arch/arm/boot/dts/uniphier-pro4-sanji.dts +++ b/arch/arm/boot/dts/uniphier-pro4-sanji.dts @@ -83,7 +83,7 @@ status = "okay"; eeprom@54 { - compatible = "st,24c64"; + compatible = "st,24c64", "atmel,24c64"; reg = <0x54>; pagesize = <32>; }; diff --git a/arch/arm/boot/dts/uniphier-pxs2-gentil.dts b/arch/arm/boot/dts/uniphier-pxs2-gentil.dts index cccc86658d20..afba587ffbbc 100644 --- a/arch/arm/boot/dts/uniphier-pxs2-gentil.dts +++ b/arch/arm/boot/dts/uniphier-pxs2-gentil.dts @@ -80,7 +80,7 @@ status = "okay"; eeprom@54 { - compatible = "st,24c64"; + compatible = "st,24c64", "atmel,24c64"; reg = <0x54>; pagesize = <32>; };
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/uniphier-pro4-ace.dts | 2 +- arch/arm/boot/dts/uniphier-pro4-sanji.dts | 2 +- arch/arm/boot/dts/uniphier-pxs2-gentil.dts | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-)