linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v4 00/20] eeprom: at24: Add OF device ID table
@ 2017-05-22 14:01 Javier Martinez Canillas
  2017-05-22 14:02 ` [PATCH v4 16/20] powerpc/5200: Add generic compatible string for I2C EEPROM Javier Martinez Canillas
                   ` (5 more replies)
  0 siblings, 6 replies; 15+ messages in thread
From: Javier Martinez Canillas @ 2017-05-22 14:01 UTC (permalink / raw)
  To: linux-kernel
  Cc: Wolfram Sang, Rob Herring, Javier Martinez Canillas,
	Benoît Cousson, Stuart Yoder, Sascha Hauer, Gregory Clement,
	Sören Brinkmann, David Lechner, Rob Herring, linux-i2c,
	Catalin Marinas, Mark Jackson, Fabio Estevam, Simon Horman,
	Michal Simek, Andy Shevchenko, Li Yang, Shawn Guo, Will Deacon,
	Florian Larysch, Magnus Damm, devicetree, Benjamin Herrenschmidt,
	Sekhar Nori, Scott Wood, Sebastian Hesselbarth, Andrew Lunn,
	Joachim Eastwood, Herbert Xu, linux-omap, Russell King,
	linux-arm-kernel, Masahiro Yamada, Michael Ellerman, Jason Cooper,
	Santosh Shilimkar, linux-renesas-soc, Hongtao Jia, Tony Lindgren,
	Paul Mackerras, Mark Rutland, Dinh Nguyen, linuxppc-dev,
	Horia Geantă

Hello Wolfram,

This series is a follow-up to patch [0] that added an OF device ID table
to the at24 EEPROM driver. As you suggested [1], this version instead of
adding entries for every used <vendor,device> tuple, only adds a single
entry for each chip type using the "atmel" vendor as a generic fallback.

This is a re-spin that addresses some issues pointed out by Rob Herring.

The first patch documents in the DT binding what's the correct vendor to
use and what are the ones that are being deprecated. The second one adds
the OF device ID table for the at24 driver and the next patches use this
vendor in the compatible string to each DTS that defines a compatible I2C
EEPROM device node.

Patches can be applied independently since the DTS changes without driver
changes are no-op and the OF table won't be used without the DTS changes.

[0]: https://lkml.org/lkml/2017/3/14/589
[1]: https://lkml.org/lkml/2017/3/15/99

Best regards,
Javier

Changes in v4:
- Document the manufacturers that have been deprecated (Rob Herring).
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).
- Only use the atmel manufacturer in the compatible string instead of
  keeping the deprecated ones (Rob Herring).

Changes in v3:
- Fix wrong .data values for "atmel,24c02" and "atmel,24c64" entries.
- Add Geert Uytterhoeven reviewed-by tag.
- Add Geert Uytterhoeven reviewed-by tag.

Changes in v2:
- Only add a single OF device ID entry for each device type (Wolfram Sang).

Javier Martinez Canillas (20):
  dt-bindings: i2c: eeprom: Document vendor to be used and deprecated
    ones
  eeprom: at24: Add OF device ID table
  ARM: dts: omap: Add generic compatible string for I2C EEPROM
  ARM: dts: turris-omnia: Add generic compatible string for I2C EEPROM
  ARM: dts: efm32: Add generic compatible string for I2C EEPROM
  ARM: dts: imx: Add generic compatible string for I2C EEPROM
  ARM: dts: keystone: Add generic compatible string for I2C EEPROM
  ARM: dts: lpc18xx: Add generic compatible string for I2C EEPROM
  ARM: dts: r7s72100: Add generic compatible string for I2C EEPROM
  ARM: dts: koelsch: Add generic compatible string for I2C EEPROM
  ARM: dts: socfpga: Add generic compatible string for I2C EEPROM
  ARM: dts: uniphier: Add generic compatible string for I2C EEPROM
  ARM: dts: zynq: Add generic compatible string for I2C EEPROM
  arm64: dts: ls1043a: Add generic compatible string for I2C EEPROM
  arm64: zynqmp: Add generic compatible string for I2C EEPROM
  powerpc/5200: Add generic compatible string for I2C EEPROM
  powerpc/fsl: Add generic compatible string for I2C EEPROM
  powerpc/512x: Add generic compatible string for I2C EEPROM
  powerpc/83xx: Add generic compatible string for I2C EEPROM
  powerpc/44x: Add generic compatible string for I2C EEPROM

 .../devicetree/bindings/eeprom/eeprom.txt          | 14 ++---
 arch/arm/boot/dts/am335x-baltos.dtsi               |  2 +-
 arch/arm/boot/dts/am335x-base0033.dts              |  2 +-
 arch/arm/boot/dts/am335x-bone-common.dtsi          | 10 ++--
 arch/arm/boot/dts/am335x-nano.dts                  |  2 +-
 arch/arm/boot/dts/am335x-pepper.dts                |  2 +-
 arch/arm/boot/dts/am335x-shc.dts                   |  2 +-
 arch/arm/boot/dts/am335x-sl50.dts                  |  2 +-
 arch/arm/boot/dts/am437x-idk-evm.dts               |  2 +-
 arch/arm/boot/dts/am437x-sk-evm.dts                |  2 +-
 arch/arm/boot/dts/am43x-epos-evm.dts               |  2 +-
 arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi    |  2 +-
 arch/arm/boot/dts/armada-385-turris-omnia.dts      |  2 +-
 arch/arm/boot/dts/efm32gg-dk3750.dts               |  2 +-
 arch/arm/boot/dts/imx27-phytec-phycard-s-som.dtsi  |  2 +-
 arch/arm/boot/dts/imx27-phytec-phycore-som.dtsi    |  2 +-
 arch/arm/boot/dts/imx28-evk.dts                    |  2 +-
 arch/arm/boot/dts/imx53-tqma53.dtsi                |  2 +-
 arch/arm/boot/dts/imx6q-cm-fx6.dts                 |  2 +-
 arch/arm/boot/dts/imx6q-utilite-pro.dts            |  2 +-
 arch/arm/boot/dts/keystone-k2e-evm.dts             |  2 +-
 arch/arm/boot/dts/keystone-k2hk-evm.dts            |  2 +-
 arch/arm/boot/dts/keystone-k2l-evm.dts             |  2 +-
 arch/arm/boot/dts/lpc4337-ciaa.dts                 |  6 +-
 arch/arm/boot/dts/lpc4350-hitex-eval.dts           |  2 +-
 arch/arm/boot/dts/lpc4357-ea4357-devkit.dts        |  2 +-
 arch/arm/boot/dts/omap3-cm-t3x.dtsi                |  2 +-
 arch/arm/boot/dts/omap3-gta04.dtsi                 |  2 +-
 arch/arm/boot/dts/omap3-sb-t35.dtsi                |  2 +-
 arch/arm/boot/dts/omap4-var-som-om44.dtsi          |  2 +-
 arch/arm/boot/dts/omap5-cm-t54.dts                 |  2 +-
 arch/arm/boot/dts/omap5-sbc-t54.dts                |  2 +-
 arch/arm/boot/dts/r7s72100-genmai.dts              |  2 +-
 arch/arm/boot/dts/r8a7791-koelsch.dts              |  2 +-
 arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts |  2 +-
 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 +-
 arch/arm/boot/dts/zynq-zc702.dts                   |  2 +-
 arch/arm/boot/dts/zynq-zc706.dts                   |  2 +-
 arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts  |  4 +-
 arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts        |  4 +-
 arch/powerpc/boot/dts/digsy_mtc.dts                |  2 +-
 arch/powerpc/boot/dts/fsl/b4qds.dtsi               |  8 +--
 arch/powerpc/boot/dts/fsl/c293pcie.dts             |  2 +-
 arch/powerpc/boot/dts/fsl/p1010rdb.dtsi            |  2 +-
 arch/powerpc/boot/dts/fsl/p1023rdb.dts             |  2 +-
 arch/powerpc/boot/dts/fsl/p2041rdb.dts             |  4 +-
 arch/powerpc/boot/dts/fsl/p3041ds.dts              |  4 +-
 arch/powerpc/boot/dts/fsl/p4080ds.dts              |  4 +-
 arch/powerpc/boot/dts/fsl/p5020ds.dts              |  4 +-
 arch/powerpc/boot/dts/fsl/p5040ds.dts              |  4 +-
 arch/powerpc/boot/dts/fsl/t208xqds.dtsi            |  8 +--
 arch/powerpc/boot/dts/fsl/t4240qds.dts             | 12 ++--
 arch/powerpc/boot/dts/fsl/t4240rdb.dts             |  6 +-
 arch/powerpc/boot/dts/mpc5121ads.dts               |  2 +-
 arch/powerpc/boot/dts/mpc8308_p1m.dts              |  2 +-
 arch/powerpc/boot/dts/mpc8349emitx.dts             |  4 +-
 arch/powerpc/boot/dts/mpc8377_rdb.dts              |  2 +-
 arch/powerpc/boot/dts/mpc8377_wlan.dts             |  2 +-
 arch/powerpc/boot/dts/mpc8378_rdb.dts              |  2 +-
 arch/powerpc/boot/dts/mpc8379_rdb.dts              |  2 +-
 arch/powerpc/boot/dts/pcm030.dts                   |  2 +-
 arch/powerpc/boot/dts/pcm032.dts                   |  2 +-
 arch/powerpc/boot/dts/warp.dts                     |  2 +-
 drivers/misc/eeprom/at24.c                         | 65 +++++++++++++++++++++-
 66 files changed, 159 insertions(+), 102 deletions(-)

-- 
2.9.3

^ permalink raw reply	[flat|nested] 15+ messages in thread

* [PATCH v4 16/20] powerpc/5200: Add generic compatible string for I2C EEPROM
  2017-05-22 14:01 [PATCH v4 00/20] eeprom: at24: Add OF device ID table Javier Martinez Canillas
@ 2017-05-22 14:02 ` Javier Martinez Canillas
  2017-05-22 14:02 ` [PATCH v4 17/20] powerpc/fsl: " Javier Martinez Canillas
                   ` (4 subsequent siblings)
  5 siblings, 0 replies; 15+ messages in thread
From: Javier Martinez Canillas @ 2017-05-22 14:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Wolfram Sang, Rob Herring, Javier Martinez Canillas, devicetree,
	Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
	Rob Herring, Mark Rutland, linuxppc-dev

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 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/powerpc/boot/dts/digsy_mtc.dts | 2 +-
 arch/powerpc/boot/dts/pcm030.dts    | 2 +-
 arch/powerpc/boot/dts/pcm032.dts    | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/boot/dts/digsy_mtc.dts b/arch/powerpc/boot/dts/digsy_mtc.dts
index 955bff629df3..c280e75c86bf 100644
--- a/arch/powerpc/boot/dts/digsy_mtc.dts
+++ b/arch/powerpc/boot/dts/digsy_mtc.dts
@@ -73,7 +73,7 @@
 
 		i2c@3d00 {
 			eeprom@50 {
-				compatible = "at,24c08";
+				compatible = "atmel,24c08";
 				reg = <0x50>;
 			};
 
diff --git a/arch/powerpc/boot/dts/pcm030.dts b/arch/powerpc/boot/dts/pcm030.dts
index 192e66af0001..dd6b8002d716 100644
--- a/arch/powerpc/boot/dts/pcm030.dts
+++ b/arch/powerpc/boot/dts/pcm030.dts
@@ -71,7 +71,7 @@
 				reg = <0x51>;
 			};
 			eeprom@52 {
-				compatible = "catalyst,24c32";
+				compatible = "atmel,24c32";
 				reg = <0x52>;
 				pagesize = <32>;
 			};
diff --git a/arch/powerpc/boot/dts/pcm032.dts b/arch/powerpc/boot/dts/pcm032.dts
index 96b139bf50e9..d77bf80e2847 100644
--- a/arch/powerpc/boot/dts/pcm032.dts
+++ b/arch/powerpc/boot/dts/pcm032.dts
@@ -75,7 +75,7 @@
 				reg = <0x51>;
 			};
 			eeprom@52 {
-				compatible = "catalyst,24c32";
+				compatible = "atmel,24c32";
 				reg = <0x52>;
 				pagesize = <32>;
 			};
-- 
2.9.3

^ permalink raw reply related	[flat|nested] 15+ messages in thread

* [PATCH v4 17/20] powerpc/fsl: Add generic compatible string for I2C EEPROM
  2017-05-22 14:01 [PATCH v4 00/20] eeprom: at24: Add OF device ID table Javier Martinez Canillas
  2017-05-22 14:02 ` [PATCH v4 16/20] powerpc/5200: Add generic compatible string for I2C EEPROM Javier Martinez Canillas
@ 2017-05-22 14:02 ` Javier Martinez Canillas
  2017-05-22 14:02 ` [PATCH v4 18/20] powerpc/512x: " Javier Martinez Canillas
                   ` (3 subsequent siblings)
  5 siblings, 0 replies; 15+ messages in thread
From: Javier Martinez Canillas @ 2017-05-22 14:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Wolfram Sang, Rob Herring, Javier Martinez Canillas, devicetree,
	Florian Larysch, Michael Ellerman, Scott Wood,
	Benjamin Herrenschmidt, Paul Mackerras, Rob Herring, Mark Rutland,
	linuxppc-dev

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 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/powerpc/boot/dts/fsl/b4qds.dtsi    |  8 ++++----
 arch/powerpc/boot/dts/fsl/c293pcie.dts  |  2 +-
 arch/powerpc/boot/dts/fsl/p1010rdb.dtsi |  2 +-
 arch/powerpc/boot/dts/fsl/p1023rdb.dts  |  2 +-
 arch/powerpc/boot/dts/fsl/p2041rdb.dts  |  4 ++--
 arch/powerpc/boot/dts/fsl/p3041ds.dts   |  4 ++--
 arch/powerpc/boot/dts/fsl/p4080ds.dts   |  4 ++--
 arch/powerpc/boot/dts/fsl/p5020ds.dts   |  4 ++--
 arch/powerpc/boot/dts/fsl/p5040ds.dts   |  4 ++--
 arch/powerpc/boot/dts/fsl/t208xqds.dtsi |  8 ++++----
 arch/powerpc/boot/dts/fsl/t4240qds.dts  | 12 ++++++------
 arch/powerpc/boot/dts/fsl/t4240rdb.dts  |  6 +++---
 12 files changed, 30 insertions(+), 30 deletions(-)

diff --git a/arch/powerpc/boot/dts/fsl/b4qds.dtsi b/arch/powerpc/boot/dts/fsl/b4qds.dtsi
index 3785ef826d07..999efd3bc167 100644
--- a/arch/powerpc/boot/dts/fsl/b4qds.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4qds.dtsi
@@ -166,19 +166,19 @@
 					reg = <0>;
 
 					eeprom@50 {
-						compatible = "at24,24c64";
+						compatible = "atmel,24c64";
 						reg = <0x50>;
 					};
 					eeprom@51 {
-						compatible = "at24,24c256";
+						compatible = "atmel,24c256";
 						reg = <0x51>;
 					};
 					eeprom@53 {
-						compatible = "at24,24c256";
+						compatible = "atmel,24c256";
 						reg = <0x53>;
 					};
 					eeprom@57 {
-						compatible = "at24,24c256";
+						compatible = "atmel,24c256";
 						reg = <0x57>;
 					};
 					rtc@68 {
diff --git a/arch/powerpc/boot/dts/fsl/c293pcie.dts b/arch/powerpc/boot/dts/fsl/c293pcie.dts
index 66709788429d..c39b007b6f2c 100644
--- a/arch/powerpc/boot/dts/fsl/c293pcie.dts
+++ b/arch/powerpc/boot/dts/fsl/c293pcie.dts
@@ -153,7 +153,7 @@
 &soc {
 	i2c@3000 {
 		eeprom@50 {
-			compatible = "st,24c1024";
+			compatible = "atmel,24c1024";
 			reg = <0x50>;
 		};
 
diff --git a/arch/powerpc/boot/dts/fsl/p1010rdb.dtsi b/arch/powerpc/boot/dts/fsl/p1010rdb.dtsi
index a8e4ba070104..56e69a3a4eb9 100644
--- a/arch/powerpc/boot/dts/fsl/p1010rdb.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p1010rdb.dtsi
@@ -89,7 +89,7 @@
 &board_soc {
 	i2c@3000 {
 		eeprom@50 {
-			compatible = "st,24c256";
+			compatible = "atmel,24c256";
 			reg = <0x50>;
 		};
 
diff --git a/arch/powerpc/boot/dts/fsl/p1023rdb.dts b/arch/powerpc/boot/dts/fsl/p1023rdb.dts
index 9716ca64651c..ead928364beb 100644
--- a/arch/powerpc/boot/dts/fsl/p1023rdb.dts
+++ b/arch/powerpc/boot/dts/fsl/p1023rdb.dts
@@ -79,7 +79,7 @@
 
 		i2c@3000 {
 			eeprom@53 {
-				compatible = "at24,24c04";
+				compatible = "atmel,24c04";
 				reg = <0x53>;
 			};
 
diff --git a/arch/powerpc/boot/dts/fsl/p2041rdb.dts b/arch/powerpc/boot/dts/fsl/p2041rdb.dts
index e50fea95a853..950816b9d6e1 100644
--- a/arch/powerpc/boot/dts/fsl/p2041rdb.dts
+++ b/arch/powerpc/boot/dts/fsl/p2041rdb.dts
@@ -127,7 +127,7 @@
 				reg = <0x48>;
 			};
 			eeprom@50 {
-				compatible = "at24,24c256";
+				compatible = "atmel,24c256";
 				reg = <0x50>;
 			};
 			rtc@68 {
@@ -142,7 +142,7 @@
 
 		i2c@118100 {
 			eeprom@50 {
-				compatible = "at24,24c256";
+				compatible = "atmel,24c256";
 				reg = <0x50>;
 			};
 		};
diff --git a/arch/powerpc/boot/dts/fsl/p3041ds.dts b/arch/powerpc/boot/dts/fsl/p3041ds.dts
index 40748e415adb..6f5f7283c533 100644
--- a/arch/powerpc/boot/dts/fsl/p3041ds.dts
+++ b/arch/powerpc/boot/dts/fsl/p3041ds.dts
@@ -124,11 +124,11 @@
 
 		i2c@118100 {
 			eeprom@51 {
-				compatible = "at24,24c256";
+				compatible = "atmel,24c256";
 				reg = <0x51>;
 			};
 			eeprom@52 {
-				compatible = "at24,24c256";
+				compatible = "atmel,24c256";
 				reg = <0x52>;
 			};
 		};
diff --git a/arch/powerpc/boot/dts/fsl/p4080ds.dts b/arch/powerpc/boot/dts/fsl/p4080ds.dts
index 816b9788d5f6..65e20152e22f 100644
--- a/arch/powerpc/boot/dts/fsl/p4080ds.dts
+++ b/arch/powerpc/boot/dts/fsl/p4080ds.dts
@@ -125,11 +125,11 @@
 
 		i2c@118100 {
 			eeprom@51 {
-				compatible = "at24,24c256";
+				compatible = "atmel,24c256";
 				reg = <0x51>;
 			};
 			eeprom@52 {
-				compatible = "at24,24c256";
+				compatible = "atmel,24c256";
 				reg = <0x52>;
 			};
 			rtc@68 {
diff --git a/arch/powerpc/boot/dts/fsl/p5020ds.dts b/arch/powerpc/boot/dts/fsl/p5020ds.dts
index cd6f37386111..b24adf902d8d 100644
--- a/arch/powerpc/boot/dts/fsl/p5020ds.dts
+++ b/arch/powerpc/boot/dts/fsl/p5020ds.dts
@@ -124,11 +124,11 @@
 
 		i2c@118100 {
 			eeprom@51 {
-				compatible = "at24,24c256";
+				compatible = "atmel,24c256";
 				reg = <0x51>;
 			};
 			eeprom@52 {
-				compatible = "at24,24c256";
+				compatible = "atmel,24c256";
 				reg = <0x52>;
 			};
 		};
diff --git a/arch/powerpc/boot/dts/fsl/p5040ds.dts b/arch/powerpc/boot/dts/fsl/p5040ds.dts
index 45084738cf4e..30850b3228e0 100644
--- a/arch/powerpc/boot/dts/fsl/p5040ds.dts
+++ b/arch/powerpc/boot/dts/fsl/p5040ds.dts
@@ -133,11 +133,11 @@
 
 		i2c@118100 {
 			eeprom@51 {
-				compatible = "at24,24c256";
+				compatible = "atmel,24c256";
 				reg = <0x51>;
 			};
 			eeprom@52 {
-				compatible = "at24,24c256";
+				compatible = "atmel,24c256";
 				reg = <0x52>;
 			};
 		};
diff --git a/arch/powerpc/boot/dts/fsl/t208xqds.dtsi b/arch/powerpc/boot/dts/fsl/t208xqds.dtsi
index ec080bd01b09..db4139999b28 100644
--- a/arch/powerpc/boot/dts/fsl/t208xqds.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t208xqds.dtsi
@@ -147,17 +147,17 @@
 					reg = <0x0>;
 
 					eeprom@50 {
-						compatible = "at24,24c512";
+						compatible = "atmel,24c512";
 						reg = <0x50>;
 					};
 
 					eeprom@51 {
-						compatible = "at24,24c02";
+						compatible = "atmel,24c02";
 						reg = <0x51>;
 					};
 
 					eeprom@57 {
-						compatible = "at24,24c02";
+						compatible = "atmel,24c02";
 						reg = <0x57>;
 					};
 
@@ -174,7 +174,7 @@
 					reg = <0x1>;
 
 					eeprom@55 {
-						compatible = "at24,24c02";
+						compatible = "atmel,24c02";
 						reg = <0x55>;
 					};
 				};
diff --git a/arch/powerpc/boot/dts/fsl/t4240qds.dts b/arch/powerpc/boot/dts/fsl/t4240qds.dts
index 9573ceada07c..c0913ac5aaad 100644
--- a/arch/powerpc/boot/dts/fsl/t4240qds.dts
+++ b/arch/powerpc/boot/dts/fsl/t4240qds.dts
@@ -377,27 +377,27 @@
 					reg = <0>;
 
 					eeprom@51 {
-						compatible = "at24,24c256";
+						compatible = "atmel,24c256";
 						reg = <0x51>;
 					};
 					eeprom@52 {
-						compatible = "at24,24c256";
+						compatible = "atmel,24c256";
 						reg = <0x52>;
 					};
 					eeprom@53 {
-						compatible = "at24,24c256";
+						compatible = "atmel,24c256";
 						reg = <0x53>;
 					};
 					eeprom@54 {
-						compatible = "at24,24c256";
+						compatible = "atmel,24c256";
 						reg = <0x54>;
 					};
 					eeprom@55 {
-						compatible = "at24,24c256";
+						compatible = "atmel,24c256";
 						reg = <0x55>;
 					};
 					eeprom@56 {
-						compatible = "at24,24c256";
+						compatible = "atmel,24c256";
 						reg = <0x56>;
 					};
 					rtc@68 {
diff --git a/arch/powerpc/boot/dts/fsl/t4240rdb.dts b/arch/powerpc/boot/dts/fsl/t4240rdb.dts
index 8166c660712a..15eb0a3f7290 100644
--- a/arch/powerpc/boot/dts/fsl/t4240rdb.dts
+++ b/arch/powerpc/boot/dts/fsl/t4240rdb.dts
@@ -130,15 +130,15 @@
 				reg = <0x2f>;
 			};
 			eeprom@52 {
-				compatible = "at24,24c256";
+				compatible = "atmel,24c256";
 				reg = <0x52>;
 			};
 			eeprom@54 {
-				compatible = "at24,24c256";
+				compatible = "atmel,24c256";
 				reg = <0x54>;
 			};
 			eeprom@56 {
-				compatible = "at24,24c256";
+				compatible = "atmel,24c256";
 				reg = <0x56>;
 			};
 			rtc@68 {
-- 
2.9.3

^ permalink raw reply related	[flat|nested] 15+ messages in thread

* [PATCH v4 18/20] powerpc/512x: Add generic compatible string for I2C EEPROM
  2017-05-22 14:01 [PATCH v4 00/20] eeprom: at24: Add OF device ID table Javier Martinez Canillas
  2017-05-22 14:02 ` [PATCH v4 16/20] powerpc/5200: Add generic compatible string for I2C EEPROM Javier Martinez Canillas
  2017-05-22 14:02 ` [PATCH v4 17/20] powerpc/fsl: " Javier Martinez Canillas
@ 2017-05-22 14:02 ` Javier Martinez Canillas
  2017-05-22 14:02 ` [PATCH v4 19/20] powerpc/83xx: " Javier Martinez Canillas
                   ` (2 subsequent siblings)
  5 siblings, 0 replies; 15+ messages in thread
From: Javier Martinez Canillas @ 2017-05-22 14:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Wolfram Sang, Rob Herring, Javier Martinez Canillas, devicetree,
	Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
	Rob Herring, Mark Rutland, linuxppc-dev

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 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/powerpc/boot/dts/mpc5121ads.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/boot/dts/mpc5121ads.dts b/arch/powerpc/boot/dts/mpc5121ads.dts
index 75888ce2c792..fcaa9bad4bda 100644
--- a/arch/powerpc/boot/dts/mpc5121ads.dts
+++ b/arch/powerpc/boot/dts/mpc5121ads.dts
@@ -94,7 +94,7 @@
 			};
 
 			eeprom@50 {
-				compatible = "at,24c32";
+				compatible = "atmel,24c32";
 				reg = <0x50>;
 			};
 
-- 
2.9.3

^ permalink raw reply related	[flat|nested] 15+ messages in thread

* [PATCH v4 19/20] powerpc/83xx: Add generic compatible string for I2C EEPROM
  2017-05-22 14:01 [PATCH v4 00/20] eeprom: at24: Add OF device ID table Javier Martinez Canillas
                   ` (2 preceding siblings ...)
  2017-05-22 14:02 ` [PATCH v4 18/20] powerpc/512x: " Javier Martinez Canillas
@ 2017-05-22 14:02 ` Javier Martinez Canillas
  2017-05-23 13:42   ` Rob Herring
  2017-05-22 14:02 ` [PATCH v4 20/20] powerpc/44x: " Javier Martinez Canillas
  2017-05-22 14:23 ` [PATCH v4 00/20] eeprom: at24: Add OF device ID table Geert Uytterhoeven
  5 siblings, 1 reply; 15+ messages in thread
From: Javier Martinez Canillas @ 2017-05-22 14:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Wolfram Sang, Rob Herring, Javier Martinez Canillas, devicetree,
	Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
	Rob Herring, Mark Rutland, linuxppc-dev

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 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/powerpc/boot/dts/mpc8308_p1m.dts  | 2 +-
 arch/powerpc/boot/dts/mpc8349emitx.dts | 4 ++--
 arch/powerpc/boot/dts/mpc8377_rdb.dts  | 2 +-
 arch/powerpc/boot/dts/mpc8377_wlan.dts | 2 +-
 arch/powerpc/boot/dts/mpc8378_rdb.dts  | 2 +-
 arch/powerpc/boot/dts/mpc8379_rdb.dts  | 2 +-
 6 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/boot/dts/mpc8308_p1m.dts b/arch/powerpc/boot/dts/mpc8308_p1m.dts
index 57f86cdf9f36..702ab4fc5b4a 100644
--- a/arch/powerpc/boot/dts/mpc8308_p1m.dts
+++ b/arch/powerpc/boot/dts/mpc8308_p1m.dts
@@ -123,7 +123,7 @@
 			interrupt-parent = <&ipic>;
 			dfsrr;
 			fram@50 {
-				compatible = "ramtron,24c64";
+				compatible = "atmel,24c64";
 				reg = <0x50>;
 			};
 		};
diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts b/arch/powerpc/boot/dts/mpc8349emitx.dts
index 90aed3ac2f69..f49d1cffd927 100644
--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -92,7 +92,7 @@
 			dfsrr;
 
 			eeprom: at24@50 {
-				compatible = "st,24c256";
+				compatible = "atmel,24c256";
 				reg = <0x50>;
 			};
 
@@ -130,7 +130,7 @@
 			};
 
 			spd: at24@51 {
-				compatible = "at24,spd";
+				compatible = "atmel,spd";
 				reg = <0x51>;
 			};
 
diff --git a/arch/powerpc/boot/dts/mpc8377_rdb.dts b/arch/powerpc/boot/dts/mpc8377_rdb.dts
index e32613963ab0..5e85d8c93bca 100644
--- a/arch/powerpc/boot/dts/mpc8377_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8377_rdb.dts
@@ -150,7 +150,7 @@
 				};
 
 				at24@50 {
-					compatible = "at24,24c256";
+					compatible = "atmel,24c256";
 					reg = <0x50>;
 				};
 
diff --git a/arch/powerpc/boot/dts/mpc8377_wlan.dts b/arch/powerpc/boot/dts/mpc8377_wlan.dts
index c0c790168b96..fee15fcbb46f 100644
--- a/arch/powerpc/boot/dts/mpc8377_wlan.dts
+++ b/arch/powerpc/boot/dts/mpc8377_wlan.dts
@@ -135,7 +135,7 @@
 				dfsrr;
 
 				at24@50 {
-					compatible = "at24,24c256";
+					compatible = "atmel,24c256";
 					reg = <0x50>;
 				};
 
diff --git a/arch/powerpc/boot/dts/mpc8378_rdb.dts b/arch/powerpc/boot/dts/mpc8378_rdb.dts
index 71842fcd621f..e973d61956b9 100644
--- a/arch/powerpc/boot/dts/mpc8378_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8378_rdb.dts
@@ -150,7 +150,7 @@
 				};
 
 				at24@50 {
-					compatible = "at24,24c256";
+					compatible = "atmel,24c256";
 					reg = <0x50>;
 				};
 
diff --git a/arch/powerpc/boot/dts/mpc8379_rdb.dts b/arch/powerpc/boot/dts/mpc8379_rdb.dts
index e442a29b2fe0..ed5d12ff2ee0 100644
--- a/arch/powerpc/boot/dts/mpc8379_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8379_rdb.dts
@@ -148,7 +148,7 @@
 				};
 
 				at24@50 {
-					compatible = "at24,24c256";
+					compatible = "atmel,24c256";
 					reg = <0x50>;
 				};
 
-- 
2.9.3

^ permalink raw reply related	[flat|nested] 15+ messages in thread

* [PATCH v4 20/20] powerpc/44x: Add generic compatible string for I2C EEPROM
  2017-05-22 14:01 [PATCH v4 00/20] eeprom: at24: Add OF device ID table Javier Martinez Canillas
                   ` (3 preceding siblings ...)
  2017-05-22 14:02 ` [PATCH v4 19/20] powerpc/83xx: " Javier Martinez Canillas
@ 2017-05-22 14:02 ` Javier Martinez Canillas
  2017-05-22 14:23 ` [PATCH v4 00/20] eeprom: at24: Add OF device ID table Geert Uytterhoeven
  5 siblings, 0 replies; 15+ messages in thread
From: Javier Martinez Canillas @ 2017-05-22 14:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Wolfram Sang, Rob Herring, Javier Martinez Canillas, devicetree,
	Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
	Rob Herring, Mark Rutland, linuxppc-dev

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 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/powerpc/boot/dts/warp.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/boot/dts/warp.dts b/arch/powerpc/boot/dts/warp.dts
index e576ee85c42f..ea9053ef4819 100644
--- a/arch/powerpc/boot/dts/warp.dts
+++ b/arch/powerpc/boot/dts/warp.dts
@@ -238,7 +238,7 @@
 
 				/* This will create 52 and 53 */
 				at24@52 {
-					compatible = "at,24c04";
+					compatible = "atmel,24c04";
 					reg = <0x52>;
 				};
 			};
-- 
2.9.3

^ permalink raw reply related	[flat|nested] 15+ messages in thread

* Re: [PATCH v4 00/20] eeprom: at24: Add OF device ID table
  2017-05-22 14:01 [PATCH v4 00/20] eeprom: at24: Add OF device ID table Javier Martinez Canillas
                   ` (4 preceding siblings ...)
  2017-05-22 14:02 ` [PATCH v4 20/20] powerpc/44x: " Javier Martinez Canillas
@ 2017-05-22 14:23 ` Geert Uytterhoeven
  2017-05-22 14:26   ` Rob Herring
  5 siblings, 1 reply; 15+ messages in thread
From: Geert Uytterhoeven @ 2017-05-22 14:23 UTC (permalink / raw)
  To: Javier Martinez Canillas
  Cc: linux-kernel@vger.kernel.org, Mark Rutland, Andrew Lunn,
	Wolfram Sang, Tony Lindgren, Catalin Marinas, Will Deacon,
	Russell King, Masahiro Yamada, Paul Mackerras, Linux I2C,
	Hongtao Jia, David Lechner, Rob Herring, Herbert Xu,
	Horia Geantă, Michael Ellerman, Magnus Damm, Michal Simek,
	Andy Shevchenko, linux-arm-kernel@lists.infradead.org,
	Benjamin Herrenschmidt, Jason Cooper, Sebastian Hesselbarth,
	devicetree@vger.kernel.org, Mark Jackson, Sekhar Nori,
	Joachim Eastwood, Stuart Yoder, Scott Wood, Simon Horman,
	Santosh Shilimkar, Gregory Clement, linux-omap@vger.kernel.org,
	Sascha Hauer, Sören Brinkmann, Florian Larysch,
	linuxppc-dev@lists.ozlabs.org, Li Yang, Linux-Renesas,
	Dinh Nguyen, Rob Herring, Benoît Cousson, Fabio Estevam,
	Shawn Guo

Hi Javier,

On Mon, May 22, 2017 at 4:01 PM, Javier Martinez Canillas
<javier@dowhile0.org> wrote:
> This series is a follow-up to patch [0] that added an OF device ID table
> to the at24 EEPROM driver. As you suggested [1], this version instead of
> adding entries for every used <vendor,device> tuple, only adds a single
> entry for each chip type using the "atmel" vendor as a generic fallback.
>
> This is a re-spin that addresses some issues pointed out by Rob Herring.
>
> The first patch documents in the DT binding what's the correct vendor to
> use and what are the ones that are being deprecated. The second one adds
> the OF device ID table for the at24 driver and the next patches use this
> vendor in the compatible string to each DTS that defines a compatible I2C
> EEPROM device node.
>
> Patches can be applied independently since the DTS changes without driver
> changes are no-op and the OF table won't be used without the DTS changes.
>
> [0]: https://lkml.org/lkml/2017/3/14/589
> [1]: https://lkml.org/lkml/2017/3/15/99
>
> Best regards,
> Javier
>
> Changes in v4:
> - Document the manufacturers that have been deprecated (Rob Herring).
> - Only use the atmel manufacturer in the compatible string instead of
>   keeping the deprecated ones (Rob Herring).

I think you're referring to this (https://lkml.org/lkml/2017/4/19/1136)?

| > --- a/arch/arm/boot/dts/am335x-baltos.dtsi
| > +++ b/arch/arm/boot/dts/am335x-baltos.dtsi
| > @@ -255,7 +255,7 @@
| >     };
| >
| >     at24@50 {
| > -           compatible = "at24,24c02";
| > +           compatible = "at24,24c02", "atmel,24c02";
|
| I think you can just drop the at24 compatibles. A new kernel doesn't
| need it. An old kernel ignores the manufacturer. I checked that u-boot
| only matches on "atmel,*", so okay there. Don't know about the *BSDs. I
| couldn't find anything.

I think you misunderstood what Rob means.

In the case above it makes sense to drop the first compatible, as "at24" is
not a manufacturer, but refers to ATMEL's "AT24" line of i2c FLASH ROMs.

However, in cases where a real vendor/part combo is specified, like on
r8a7791-koelsch.dts:

-               compatible = "renesas,24c02";
+               compatible = "atmel,24c02";

you do want to keep the real vendor/part combo, i.e.

     compatible = "renesas,24c02", "atmel,24c02";

like in v3, which is what I gave my Reviewed-by for.

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH v4 00/20] eeprom: at24: Add OF device ID table
  2017-05-22 14:23 ` [PATCH v4 00/20] eeprom: at24: Add OF device ID table Geert Uytterhoeven
@ 2017-05-22 14:26   ` Rob Herring
  2017-05-22 14:46     ` Javier Martinez Canillas
  0 siblings, 1 reply; 15+ messages in thread
From: Rob Herring @ 2017-05-22 14:26 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Javier Martinez Canillas, linux-kernel@vger.kernel.org,
	Mark Rutland, Andrew Lunn, Wolfram Sang, Tony Lindgren,
	Catalin Marinas, Will Deacon, Russell King, Masahiro Yamada,
	Paul Mackerras, Linux I2C, Hongtao Jia, David Lechner, Herbert Xu,
	Horia Geantă, Michael Ellerman, Magnus Damm, Michal Simek,
	Andy Shevchenko, linux-arm-kernel@lists.infradead.org,
	Benjamin Herrenschmidt, Jason Cooper, Sebastian Hesselbarth,
	devicetree@vger.kernel.org, Mark Jackson, Sekhar Nori,
	Joachim Eastwood, Stuart Yoder, Scott Wood, Simon Horman,
	Santosh Shilimkar, Gregory Clement, linux-omap@vger.kernel.org,
	Sascha Hauer, Sören Brinkmann, Florian Larysch,
	linuxppc-dev@lists.ozlabs.org, Li Yang, Linux-Renesas,
	Dinh Nguyen, Benoît Cousson, Fabio Estevam, Shawn Guo

On Mon, May 22, 2017 at 9:23 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Javier,
>
> On Mon, May 22, 2017 at 4:01 PM, Javier Martinez Canillas
> <javier@dowhile0.org> wrote:
>> This series is a follow-up to patch [0] that added an OF device ID table
>> to the at24 EEPROM driver. As you suggested [1], this version instead of
>> adding entries for every used <vendor,device> tuple, only adds a single
>> entry for each chip type using the "atmel" vendor as a generic fallback.
>>
>> This is a re-spin that addresses some issues pointed out by Rob Herring.
>>
>> The first patch documents in the DT binding what's the correct vendor to
>> use and what are the ones that are being deprecated. The second one adds
>> the OF device ID table for the at24 driver and the next patches use this
>> vendor in the compatible string to each DTS that defines a compatible I2C
>> EEPROM device node.
>>
>> Patches can be applied independently since the DTS changes without driver
>> changes are no-op and the OF table won't be used without the DTS changes.
>>
>> [0]: https://lkml.org/lkml/2017/3/14/589
>> [1]: https://lkml.org/lkml/2017/3/15/99
>>
>> Best regards,
>> Javier
>>
>> Changes in v4:
>> - Document the manufacturers that have been deprecated (Rob Herring).
>> - Only use the atmel manufacturer in the compatible string instead of
>>   keeping the deprecated ones (Rob Herring).
>
> I think you're referring to this (https://lkml.org/lkml/2017/4/19/1136)?
>
> | > --- a/arch/arm/boot/dts/am335x-baltos.dtsi
> | > +++ b/arch/arm/boot/dts/am335x-baltos.dtsi
> | > @@ -255,7 +255,7 @@
> | >     };
> | >
> | >     at24@50 {
> | > -           compatible = "at24,24c02";
> | > +           compatible = "at24,24c02", "atmel,24c02";
> |
> | I think you can just drop the at24 compatibles. A new kernel doesn't
> | need it. An old kernel ignores the manufacturer. I checked that u-boot
> | only matches on "atmel,*", so okay there. Don't know about the *BSDs. I
> | couldn't find anything.
>
> I think you misunderstood what Rob means.
>
> In the case above it makes sense to drop the first compatible, as "at24" is
> not a manufacturer, but refers to ATMEL's "AT24" line of i2c FLASH ROMs.
>
> However, in cases where a real vendor/part combo is specified, like on
> r8a7791-koelsch.dts:
>
> -               compatible = "renesas,24c02";
> +               compatible = "atmel,24c02";
>
> you do want to keep the real vendor/part combo, i.e.
>
>      compatible = "renesas,24c02", "atmel,24c02";

Yes, Geert is correct.

Rob

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH v4 00/20] eeprom: at24: Add OF device ID table
  2017-05-22 14:26   ` Rob Herring
@ 2017-05-22 14:46     ` Javier Martinez Canillas
  2017-05-22 16:52       ` Rob Herring
  0 siblings, 1 reply; 15+ messages in thread
From: Javier Martinez Canillas @ 2017-05-22 14:46 UTC (permalink / raw)
  To: Rob Herring
  Cc: Geert Uytterhoeven, linux-kernel@vger.kernel.org, Mark Rutland,
	Andrew Lunn, Wolfram Sang, Tony Lindgren, Catalin Marinas,
	Will Deacon, Russell King, Masahiro Yamada, Paul Mackerras,
	Linux I2C, Hongtao Jia, David Lechner, Herbert Xu,
	Horia Geantă, Michael Ellerman, Magnus Damm, Michal Simek,
	Andy Shevchenko, linux-arm-kernel@lists.infradead.org,
	Benjamin Herrenschmidt, Jason Cooper, Sebastian Hesselbarth,
	devicetree@vger.kernel.org, Mark Jackson, Sekhar Nori,
	Joachim Eastwood, Stuart Yoder, Scott Wood, Simon Horman,
	Santosh Shilimkar, Gregory Clement, linux-omap@vger.kernel.org,
	Sascha Hauer, Sören Brinkmann, Florian Larysch,
	linuxppc-dev@lists.ozlabs.org, Li Yang, Linux-Renesas,
	Dinh Nguyen, Benoît Cousson, Fabio Estevam, Shawn Guo

Hello Geert and Rob,

On Mon, May 22, 2017 at 4:26 PM, Rob Herring <robh@kernel.org> wrote:
> On Mon, May 22, 2017 at 9:23 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> Hi Javier,
>>
>> On Mon, May 22, 2017 at 4:01 PM, Javier Martinez Canillas
>> <javier@dowhile0.org> wrote:
>>> This series is a follow-up to patch [0] that added an OF device ID table
>>> to the at24 EEPROM driver. As you suggested [1], this version instead of
>>> adding entries for every used <vendor,device> tuple, only adds a single
>>> entry for each chip type using the "atmel" vendor as a generic fallback.
>>>
>>> This is a re-spin that addresses some issues pointed out by Rob Herring.
>>>
>>> The first patch documents in the DT binding what's the correct vendor to
>>> use and what are the ones that are being deprecated. The second one adds
>>> the OF device ID table for the at24 driver and the next patches use this
>>> vendor in the compatible string to each DTS that defines a compatible I2C
>>> EEPROM device node.
>>>
>>> Patches can be applied independently since the DTS changes without driver
>>> changes are no-op and the OF table won't be used without the DTS changes.
>>>
>>> [0]: https://lkml.org/lkml/2017/3/14/589
>>> [1]: https://lkml.org/lkml/2017/3/15/99
>>>
>>> Best regards,
>>> Javier
>>>
>>> Changes in v4:
>>> - Document the manufacturers that have been deprecated (Rob Herring).
>>> - Only use the atmel manufacturer in the compatible string instead of
>>>   keeping the deprecated ones (Rob Herring).
>>
>> I think you're referring to this (https://lkml.org/lkml/2017/4/19/1136)?
>>
>> | > --- a/arch/arm/boot/dts/am335x-baltos.dtsi
>> | > +++ b/arch/arm/boot/dts/am335x-baltos.dtsi
>> | > @@ -255,7 +255,7 @@
>> | >     };
>> | >
>> | >     at24@50 {
>> | > -           compatible = "at24,24c02";
>> | > +           compatible = "at24,24c02", "atmel,24c02";
>> |
>> | I think you can just drop the at24 compatibles. A new kernel doesn't
>> | need it. An old kernel ignores the manufacturer. I checked that u-boot
>> | only matches on "atmel,*", so okay there. Don't know about the *BSDs. I
>> | couldn't find anything.
>>
>> I think you misunderstood what Rob means.
>>
>> In the case above it makes sense to drop the first compatible, as "at24" is
>> not a manufacturer, but refers to ATMEL's "AT24" line of i2c FLASH ROMs.
>>
>> However, in cases where a real vendor/part combo is specified, like on
>> r8a7791-koelsch.dts:
>>
>> -               compatible = "renesas,24c02";
>> +               compatible = "atmel,24c02";
>>
>> you do want to keep the real vendor/part combo, i.e.
>>
>>      compatible = "renesas,24c02", "atmel,24c02";
>
> Yes, Geert is correct.
>

Sorry for misunderstanding your previous comment...

How this should be documented in the DT binding? Should I include
"renesas" as a valid manufacturer or only list the used
<vendor,device> pairs (i.e: "renesas,24c02")?

I also wonder why this is really needed if AFAIU "renesas,24c02" is
compatible with "atmel,24c02". IOW, the driver doesn't need to
differentiate between the two since the devices are the same and will
always match using "atmel,24c02".

> Rob

Best regards,
Javier

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH v4 00/20] eeprom: at24: Add OF device ID table
  2017-05-22 14:46     ` Javier Martinez Canillas
@ 2017-05-22 16:52       ` Rob Herring
  2017-05-22 17:15         ` Javier Martinez Canillas
  0 siblings, 1 reply; 15+ messages in thread
From: Rob Herring @ 2017-05-22 16:52 UTC (permalink / raw)
  To: Javier Martinez Canillas
  Cc: Geert Uytterhoeven, linux-kernel@vger.kernel.org, Mark Rutland,
	Andrew Lunn, Wolfram Sang, Tony Lindgren, Catalin Marinas,
	Will Deacon, Russell King, Masahiro Yamada, Paul Mackerras,
	Linux I2C, Hongtao Jia, David Lechner, Herbert Xu,
	Horia Geantă, Michael Ellerman, Magnus Damm, Michal Simek,
	Andy Shevchenko, linux-arm-kernel@lists.infradead.org,
	Benjamin Herrenschmidt, Jason Cooper, Sebastian Hesselbarth,
	devicetree@vger.kernel.org, Mark Jackson, Sekhar Nori,
	Joachim Eastwood, Stuart Yoder, Scott Wood, Simon Horman,
	Santosh Shilimkar, Gregory Clement, linux-omap@vger.kernel.org,
	Sascha Hauer, Sören Brinkmann, Florian Larysch,
	linuxppc-dev@lists.ozlabs.org, Li Yang, Linux-Renesas,
	Dinh Nguyen, Benoît Cousson, Fabio Estevam, Shawn Guo

On Mon, May 22, 2017 at 9:46 AM, Javier Martinez Canillas
<javier@dowhile0.org> wrote:
> Hello Geert and Rob,
>
> On Mon, May 22, 2017 at 4:26 PM, Rob Herring <robh@kernel.org> wrote:
>> On Mon, May 22, 2017 at 9:23 AM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>>> Hi Javier,
>>>
>>> On Mon, May 22, 2017 at 4:01 PM, Javier Martinez Canillas
>>> <javier@dowhile0.org> wrote:
>>>> This series is a follow-up to patch [0] that added an OF device ID table
>>>> to the at24 EEPROM driver. As you suggested [1], this version instead of
>>>> adding entries for every used <vendor,device> tuple, only adds a single
>>>> entry for each chip type using the "atmel" vendor as a generic fallback.
>>>>
>>>> This is a re-spin that addresses some issues pointed out by Rob Herring.
>>>>
>>>> The first patch documents in the DT binding what's the correct vendor to
>>>> use and what are the ones that are being deprecated. The second one adds
>>>> the OF device ID table for the at24 driver and the next patches use this
>>>> vendor in the compatible string to each DTS that defines a compatible I2C
>>>> EEPROM device node.
>>>>
>>>> Patches can be applied independently since the DTS changes without driver
>>>> changes are no-op and the OF table won't be used without the DTS changes.
>>>>
>>>> [0]: https://lkml.org/lkml/2017/3/14/589
>>>> [1]: https://lkml.org/lkml/2017/3/15/99
>>>>
>>>> Best regards,
>>>> Javier
>>>>
>>>> Changes in v4:
>>>> - Document the manufacturers that have been deprecated (Rob Herring).
>>>> - Only use the atmel manufacturer in the compatible string instead of
>>>>   keeping the deprecated ones (Rob Herring).
>>>
>>> I think you're referring to this (https://lkml.org/lkml/2017/4/19/1136)?
>>>
>>> | > --- a/arch/arm/boot/dts/am335x-baltos.dtsi
>>> | > +++ b/arch/arm/boot/dts/am335x-baltos.dtsi
>>> | > @@ -255,7 +255,7 @@
>>> | >     };
>>> | >
>>> | >     at24@50 {
>>> | > -           compatible = "at24,24c02";
>>> | > +           compatible = "at24,24c02", "atmel,24c02";
>>> |
>>> | I think you can just drop the at24 compatibles. A new kernel doesn't
>>> | need it. An old kernel ignores the manufacturer. I checked that u-boot
>>> | only matches on "atmel,*", so okay there. Don't know about the *BSDs. I
>>> | couldn't find anything.
>>>
>>> I think you misunderstood what Rob means.
>>>
>>> In the case above it makes sense to drop the first compatible, as "at24" is
>>> not a manufacturer, but refers to ATMEL's "AT24" line of i2c FLASH ROMs.
>>>
>>> However, in cases where a real vendor/part combo is specified, like on
>>> r8a7791-koelsch.dts:
>>>
>>> -               compatible = "renesas,24c02";
>>> +               compatible = "atmel,24c02";
>>>
>>> you do want to keep the real vendor/part combo, i.e.
>>>
>>>      compatible = "renesas,24c02", "atmel,24c02";
>>
>> Yes, Geert is correct.
>>
>
> Sorry for misunderstanding your previous comment...
>
> How this should be documented in the DT binding? Should I include
> "renesas" as a valid manufacturer or only list the used
> <vendor,device> pairs (i.e: "renesas,24c02")?

However you are handling any of the vendors. I'll have to go look.

> I also wonder why this is really needed if AFAIU "renesas,24c02" is
> compatible with "atmel,24c02". IOW, the driver doesn't need to
> differentiate between the two since the devices are the same and will
> always match using "atmel,24c02".

It is needed, so that when a difference is found, it can be handled
without updating the DT.

Rob

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH v4 00/20] eeprom: at24: Add OF device ID table
  2017-05-22 16:52       ` Rob Herring
@ 2017-05-22 17:15         ` Javier Martinez Canillas
  2017-05-22 19:30           ` Geert Uytterhoeven
  0 siblings, 1 reply; 15+ messages in thread
From: Javier Martinez Canillas @ 2017-05-22 17:15 UTC (permalink / raw)
  To: Rob Herring
  Cc: Geert Uytterhoeven, linux-kernel@vger.kernel.org, Mark Rutland,
	Andrew Lunn, Wolfram Sang, Tony Lindgren, Catalin Marinas,
	Will Deacon, Russell King, Masahiro Yamada, Paul Mackerras,
	Linux I2C, Hongtao Jia, David Lechner, Herbert Xu,
	Horia Geantă, Michael Ellerman, Magnus Damm, Michal Simek,
	Andy Shevchenko, linux-arm-kernel@lists.infradead.org,
	Benjamin Herrenschmidt, Jason Cooper, Sebastian Hesselbarth,
	devicetree@vger.kernel.org, Mark Jackson, Sekhar Nori,
	Joachim Eastwood, Stuart Yoder, Scott Wood, Simon Horman,
	Santosh Shilimkar, Gregory Clement, linux-omap@vger.kernel.org,
	Sascha Hauer, Sören Brinkmann, Florian Larysch,
	linuxppc-dev@lists.ozlabs.org, Li Yang, Linux-Renesas,
	Dinh Nguyen, Benoît Cousson, Fabio Estevam, Shawn Guo

Hello Rob,

Thanks a lot for your feedback.

On Mon, May 22, 2017 at 6:52 PM, Rob Herring <robh@kernel.org> wrote:
> On Mon, May 22, 2017 at 9:46 AM, Javier Martinez Canillas
> <javier@dowhile0.org> wrote:

[snip]

>>>> | >
>>>> | >     at24@50 {
>>>> | > -           compatible = "at24,24c02";
>>>> | > +           compatible = "at24,24c02", "atmel,24c02";
>>>> |
>>>> | I think you can just drop the at24 compatibles. A new kernel doesn't
>>>> | need it. An old kernel ignores the manufacturer. I checked that u-boot
>>>> | only matches on "atmel,*", so okay there. Don't know about the *BSDs. I
>>>> | couldn't find anything.
>>>>
>>>> I think you misunderstood what Rob means.
>>>>
>>>> In the case above it makes sense to drop the first compatible, as "at24" is
>>>> not a manufacturer, but refers to ATMEL's "AT24" line of i2c FLASH ROMs.
>>>>
>>>> However, in cases where a real vendor/part combo is specified, like on
>>>> r8a7791-koelsch.dts:
>>>>
>>>> -               compatible = "renesas,24c02";
>>>> +               compatible = "atmel,24c02";
>>>>
>>>> you do want to keep the real vendor/part combo, i.e.
>>>>
>>>>      compatible = "renesas,24c02", "atmel,24c02";
>>>
>>> Yes, Geert is correct.
>>>
>>
>> Sorry for misunderstanding your previous comment...
>>
>> How this should be documented in the DT binding? Should I include
>> "renesas" as a valid manufacturer or only list the used
>> <vendor,device> pairs (i.e: "renesas,24c02")?
>
> However you are handling any of the vendors. I'll have to go look.
>

The current DT binding is quite lax when describing this. From
Documentation/devicetree/bindings/eeprom/eeprom.txt:

----------------------------------
EEPROMs (I2C)

Required properties:

  - compatible : should be "<manufacturer>,<type>", like these:

"atmel,24c00", "atmel,24c01", "atmel,24c02", "atmel,24c04",
"atmel,24c08", "atmel,24c16", "atmel,24c32", "atmel,24c64",
"atmel,24c128", "atmel,24c256", "atmel,24c512", "atmel,24c1024"

"catalyst,24c32"

"microchip,24c128"

"ramtron,24c64"

"renesas,r1ex24002"

If there is no specific driver for <manufacturer>, a generic
driver based on <type> is selected. Possible types are:
"24c00", "24c01", "24c02", "24c04", "24c08", "24c16", "24c32", "24c64",
"24c128", "24c256", "24c512", "24c1024", "spd"

  - reg : the I2C address of the EEPROM
----------------------------------

I think though that this is one of the cases where the Linux I2C
subsystem matching logic is leaking into the DT binding doc, since the
manufacturer prefix is ignored by the I2C core (the I2C device ID
table is used to match and to report a MODALIAS).

But I'll keep the description generic as it is now and only mention
the atmel variants (at and at24) as deprecated then.

>> I also wonder why this is really needed if AFAIU "renesas,24c02" is
>> compatible with "atmel,24c02". IOW, the driver doesn't need to
>> differentiate between the two since the devices are the same and will
>> always match using "atmel,24c02".
>
> It is needed, so that when a difference is found, it can be handled
> without updating the DT.
>

Yes, I understand this. What I tried to ask is if there could really
be a difference for the same chip type between different vendors, or
is just that people were using other manufacturers in the compatible
string as a consequence of the DT binding doc and the I2C core
ignoring the vendor prefix.

I don't mind though, I will leave the manufacturers that are different
than the atmel variants in the mainline DTS as you and Geert asked.

> Rob

Best regards,
Javier

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH v4 00/20] eeprom: at24: Add OF device ID table
  2017-05-22 17:15         ` Javier Martinez Canillas
@ 2017-05-22 19:30           ` Geert Uytterhoeven
  2017-05-22 19:39             ` Javier Martinez Canillas
  0 siblings, 1 reply; 15+ messages in thread
From: Geert Uytterhoeven @ 2017-05-22 19:30 UTC (permalink / raw)
  To: Javier Martinez Canillas
  Cc: Rob Herring, linux-kernel@vger.kernel.org, Mark Rutland,
	Andrew Lunn, Wolfram Sang, Tony Lindgren, Catalin Marinas,
	Will Deacon, Russell King, Masahiro Yamada, Paul Mackerras,
	Linux I2C, Hongtao Jia, David Lechner, Herbert Xu,
	Horia Geantă, Michael Ellerman, Magnus Damm, Michal Simek,
	Andy Shevchenko, linux-arm-kernel@lists.infradead.org,
	Benjamin Herrenschmidt, Jason Cooper, Sebastian Hesselbarth,
	devicetree@vger.kernel.org, Mark Jackson, Sekhar Nori,
	Joachim Eastwood, Stuart Yoder, Scott Wood, Simon Horman,
	Santosh Shilimkar, Gregory Clement, linux-omap@vger.kernel.org,
	Sascha Hauer, Sören Brinkmann, Florian Larysch,
	linuxppc-dev@lists.ozlabs.org, Li Yang, Linux-Renesas,
	Dinh Nguyen, Benoît Cousson, Fabio Estevam, Shawn Guo

Hi Javier,

On Mon, May 22, 2017 at 7:15 PM, Javier Martinez Canillas
<javier@dowhile0.org> wrote:
>>> I also wonder why this is really needed if AFAIU "renesas,24c02" is
>>> compatible with "atmel,24c02". IOW, the driver doesn't need to
>>> differentiate between the two since the devices are the same and will
>>> always match using "atmel,24c02".
>>
>> It is needed, so that when a difference is found, it can be handled
>> without updating the DT.
>
> Yes, I understand this. What I tried to ask is if there could really
> be a difference for the same chip type between different vendors, or
> is just that people were using other manufacturers in the compatible
> string as a consequence of the DT binding doc and the I2C core
> ignoring the vendor prefix.

The devices from different vendors are not the same. They contain FLASH
ROM of a specific size, and glue logic to expose an i2c slave
interface providing
an AT24-compatible command set.  They should behave similar within
the limits of the AT24 "spec".  But the actual implementation may be different.

> I don't mind though, I will leave the manufacturers that are different
> than the atmel variants in the mainline DTS as you and Geert asked.

OK, thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH v4 00/20] eeprom: at24: Add OF device ID table
  2017-05-22 19:30           ` Geert Uytterhoeven
@ 2017-05-22 19:39             ` Javier Martinez Canillas
  0 siblings, 0 replies; 15+ messages in thread
From: Javier Martinez Canillas @ 2017-05-22 19:39 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Rob Herring, linux-kernel@vger.kernel.org, Mark Rutland,
	Andrew Lunn, Wolfram Sang, Tony Lindgren, Catalin Marinas,
	Will Deacon, Russell King, Masahiro Yamada, Paul Mackerras,
	Linux I2C, Hongtao Jia, David Lechner, Herbert Xu,
	Horia Geantă, Michael Ellerman, Magnus Damm, Michal Simek,
	Andy Shevchenko, linux-arm-kernel@lists.infradead.org,
	Benjamin Herrenschmidt, Jason Cooper, Sebastian Hesselbarth,
	devicetree@vger.kernel.org, Mark Jackson, Sekhar Nori,
	Joachim Eastwood, Stuart Yoder, Scott Wood, Simon Horman,
	Santosh Shilimkar, Gregory Clement, linux-omap@vger.kernel.org,
	Sascha Hauer, Sören Brinkmann, Florian Larysch,
	linuxppc-dev@lists.ozlabs.org, Li Yang, Linux-Renesas,
	Dinh Nguyen, Benoît Cousson, Fabio Estevam, Shawn Guo

Hello Geert,

On Mon, May 22, 2017 at 9:30 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Javier,
>
> On Mon, May 22, 2017 at 7:15 PM, Javier Martinez Canillas
> <javier@dowhile0.org> wrote:
>>>> I also wonder why this is really needed if AFAIU "renesas,24c02" is
>>>> compatible with "atmel,24c02". IOW, the driver doesn't need to
>>>> differentiate between the two since the devices are the same and will
>>>> always match using "atmel,24c02".
>>>
>>> It is needed, so that when a difference is found, it can be handled
>>> without updating the DT.
>>
>> Yes, I understand this. What I tried to ask is if there could really
>> be a difference for the same chip type between different vendors, or
>> is just that people were using other manufacturers in the compatible
>> string as a consequence of the DT binding doc and the I2C core
>> ignoring the vendor prefix.
>
> The devices from different vendors are not the same. They contain FLASH
> ROM of a specific size, and glue logic to expose an i2c slave
> interface providing
> an AT24-compatible command set.  They should behave similar within
> the limits of the AT24 "spec".  But the actual implementation may be different.
>

I see, really appreciate your explanation. I'm not familiar with these
devices and driver but the patch-series are needed in order to make
sure that no regressions will happen once the I2C core reports a
proper OF modalias.

>> I don't mind though, I will leave the manufacturers that are different
>> than the atmel variants in the mainline DTS as you and Geert asked.
>
> OK, thanks!
>

Thanks a lot for your feedback!

> Gr{oetje,eeting}s,
>
>                         Geert
>
> --

Best regards,
Javier

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH v4 19/20] powerpc/83xx: Add generic compatible string for I2C EEPROM
  2017-05-22 14:02 ` [PATCH v4 19/20] powerpc/83xx: " Javier Martinez Canillas
@ 2017-05-23 13:42   ` Rob Herring
  2017-05-23 13:49     ` Javier Martinez Canillas
  0 siblings, 1 reply; 15+ messages in thread
From: Rob Herring @ 2017-05-23 13:42 UTC (permalink / raw)
  To: Javier Martinez Canillas
  Cc: linux-kernel@vger.kernel.org, Wolfram Sang,
	devicetree@vger.kernel.org, Michael Ellerman,
	Benjamin Herrenschmidt, Paul Mackerras, Mark Rutland,
	linuxppc-dev

On Mon, May 22, 2017 at 9:02 AM, Javier Martinez Canillas
<javier@dowhile0.org> 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>
>
> ---
>
> 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/powerpc/boot/dts/mpc8308_p1m.dts  | 2 +-
>  arch/powerpc/boot/dts/mpc8349emitx.dts | 4 ++--
>  arch/powerpc/boot/dts/mpc8377_rdb.dts  | 2 +-
>  arch/powerpc/boot/dts/mpc8377_wlan.dts | 2 +-
>  arch/powerpc/boot/dts/mpc8378_rdb.dts  | 2 +-
>  arch/powerpc/boot/dts/mpc8379_rdb.dts  | 2 +-
>  6 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc8308_p1m.dts b/arch/powerpc/boot/dts/mpc8308_p1m.dts
> index 57f86cdf9f36..702ab4fc5b4a 100644
> --- a/arch/powerpc/boot/dts/mpc8308_p1m.dts
> +++ b/arch/powerpc/boot/dts/mpc8308_p1m.dts
> @@ -123,7 +123,7 @@
>                         interrupt-parent = <&ipic>;
>                         dfsrr;
>                         fram@50 {
> -                               compatible = "ramtron,24c64";
> +                               compatible = "atmel,24c64";

This should be '"ramtron,24c64", "atmel,24c64"'

>                                 reg = <0x50>;
>                         };
>                 };
> diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts b/arch/powerpc/boot/dts/mpc8349emitx.dts
> index 90aed3ac2f69..f49d1cffd927 100644
> --- a/arch/powerpc/boot/dts/mpc8349emitx.dts
> +++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
> @@ -92,7 +92,7 @@
>                         dfsrr;
>
>                         eeprom: at24@50 {
> -                               compatible = "st,24c256";
> +                               compatible = "atmel,24c256";

Similar for this one.

>                                 reg = <0x50>;
>                         };
>
> @@ -130,7 +130,7 @@
>                         };
>
>                         spd: at24@51 {
> -                               compatible = "at24,spd";
> +                               compatible = "atmel,spd";

This is fine because at24 is not a vendor.

Rob

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH v4 19/20] powerpc/83xx: Add generic compatible string for I2C EEPROM
  2017-05-23 13:42   ` Rob Herring
@ 2017-05-23 13:49     ` Javier Martinez Canillas
  0 siblings, 0 replies; 15+ messages in thread
From: Javier Martinez Canillas @ 2017-05-23 13:49 UTC (permalink / raw)
  To: Rob Herring
  Cc: linux-kernel@vger.kernel.org, Wolfram Sang,
	devicetree@vger.kernel.org, Michael Ellerman,
	Benjamin Herrenschmidt, Paul Mackerras, Mark Rutland,
	linuxppc-dev

Hello Rob,

On Tue, May 23, 2017 at 3:42 PM, Rob Herring <robh@kernel.org> wrote:
> On Mon, May 22, 2017 at 9:02 AM, Javier Martinez Canillas
> <javier@dowhile0.org> 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>
>>
>> ---
>>
>> 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/powerpc/boot/dts/mpc8308_p1m.dts  | 2 +-
>>  arch/powerpc/boot/dts/mpc8349emitx.dts | 4 ++--
>>  arch/powerpc/boot/dts/mpc8377_rdb.dts  | 2 +-
>>  arch/powerpc/boot/dts/mpc8377_wlan.dts | 2 +-
>>  arch/powerpc/boot/dts/mpc8378_rdb.dts  | 2 +-
>>  arch/powerpc/boot/dts/mpc8379_rdb.dts  | 2 +-
>>  6 files changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/powerpc/boot/dts/mpc8308_p1m.dts b/arch/powerpc/boot/dts/mpc8308_p1m.dts
>> index 57f86cdf9f36..702ab4fc5b4a 100644
>> --- a/arch/powerpc/boot/dts/mpc8308_p1m.dts
>> +++ b/arch/powerpc/boot/dts/mpc8308_p1m.dts
>> @@ -123,7 +123,7 @@
>>                         interrupt-parent = <&ipic>;
>>                         dfsrr;
>>                         fram@50 {
>> -                               compatible = "ramtron,24c64";
>> +                               compatible = "atmel,24c64";
>
> This should be '"ramtron,24c64", "atmel,24c64"'
>

Yes, I (hopefully) fixed all the occurrences in the v5 that I posted
today, you are cc'ed on that series too.

Again, sorry for misunderstanding your comment on v3.

Best regards,
Javier

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2017-05-23 13:49 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-05-22 14:01 [PATCH v4 00/20] eeprom: at24: Add OF device ID table Javier Martinez Canillas
2017-05-22 14:02 ` [PATCH v4 16/20] powerpc/5200: Add generic compatible string for I2C EEPROM Javier Martinez Canillas
2017-05-22 14:02 ` [PATCH v4 17/20] powerpc/fsl: " Javier Martinez Canillas
2017-05-22 14:02 ` [PATCH v4 18/20] powerpc/512x: " Javier Martinez Canillas
2017-05-22 14:02 ` [PATCH v4 19/20] powerpc/83xx: " Javier Martinez Canillas
2017-05-23 13:42   ` Rob Herring
2017-05-23 13:49     ` Javier Martinez Canillas
2017-05-22 14:02 ` [PATCH v4 20/20] powerpc/44x: " Javier Martinez Canillas
2017-05-22 14:23 ` [PATCH v4 00/20] eeprom: at24: Add OF device ID table Geert Uytterhoeven
2017-05-22 14:26   ` Rob Herring
2017-05-22 14:46     ` Javier Martinez Canillas
2017-05-22 16:52       ` Rob Herring
2017-05-22 17:15         ` Javier Martinez Canillas
2017-05-22 19:30           ` Geert Uytterhoeven
2017-05-22 19:39             ` Javier Martinez Canillas

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).