* [PATCH v3 12/21] ARM: dts: socfpga: Add generic compatible string for I2C EEPROM
From: Javier Martinez Canillas @ 2017-04-14 1:04 UTC (permalink / raw)
To: linux-kernel
Cc: Mark Rutland, devicetree, Dinh Nguyen, Wolfram Sang, Russell King,
Javier Martinez Canillas, Rob Herring, linux-arm-kernel
In-Reply-To: <20170414010445.21727-1-javier@osg.samsung.com>
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@osg.samsung.com>
---
Changes in v3: None
Changes in v2: None
arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts b/arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts
index 363ee62457fe..24f566d81667 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts
@@ -294,7 +294,7 @@
clock-frequency = <100000>;
at24@50 {
- compatible = "at24,24c02";
+ compatible = "at24,24c02", "atmel,24c02";
pagesize = <8>;
reg = <0x50>;
};
--
2.9.3
^ permalink raw reply related
* [PATCH v3 11/21] ARM: dts: koelsch: Add generic compatible string for I2C EEPROM
From: Javier Martinez Canillas @ 2017-04-14 1:04 UTC (permalink / raw)
To: linux-kernel
Cc: Wolfram Sang, Javier Martinez Canillas, Simon Horman, devicetree,
Russell King, linux-renesas-soc, Rob Herring, Magnus Damm,
Mark Rutland, linux-arm-kernel
In-Reply-To: <20170414010445.21727-1-javier@osg.samsung.com>
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@osg.samsung.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Changes in v3:
- Add Geert Uytterhoeven reviewed-by tag.
Changes in v2: None
arch/arm/boot/dts/r8a7791-koelsch.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts b/arch/arm/boot/dts/r8a7791-koelsch.dts
index 001e6116c47c..dc8ed02de707 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -702,7 +702,7 @@
};
eeprom@50 {
- compatible = "renesas,24c02";
+ compatible = "renesas,24c02", "atmel,24c02";
reg = <0x50>;
pagesize = <16>;
};
--
2.9.3
^ permalink raw reply related
* [PATCH v3 10/21] ARM: dts: r7s72100: Add generic compatible string for I2C EEPROM
From: Javier Martinez Canillas @ 2017-04-14 1:04 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Wolfram Sang, Javier Martinez Canillas, Simon Horman,
devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Magnus Damm, Mark Rutland,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170414010445.21727-1-javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.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-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
---
Changes in v3:
- Add Geert Uytterhoeven reviewed-by tag.
Changes in v2: None
arch/arm/boot/dts/r7s72100-genmai.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r7s72100-genmai.dts b/arch/arm/boot/dts/r7s72100-genmai.dts
index 52a7b586bac7..b0db621ff176 100644
--- a/arch/arm/boot/dts/r7s72100-genmai.dts
+++ b/arch/arm/boot/dts/r7s72100-genmai.dts
@@ -57,7 +57,7 @@
clock-frequency = <400000>;
eeprom@50 {
- compatible = "renesas,24c128";
+ compatible = "renesas,24c128", "atmel,24c128";
reg = <0x50>;
pagesize = <64>;
};
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v3 09/21] ARM: dts: lpc18xx: Add generic compatible string for I2C EEPROM
From: Javier Martinez Canillas @ 2017-04-14 1:04 UTC (permalink / raw)
To: linux-kernel
Cc: Mark Rutland, devicetree, Wolfram Sang, Joachim Eastwood,
Russell King, Javier Martinez Canillas, Rob Herring,
linux-arm-kernel
In-Reply-To: <20170414010445.21727-1-javier@osg.samsung.com>
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@osg.samsung.com>
---
Changes in v3: None
Changes in v2: None
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 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/lpc4337-ciaa.dts b/arch/arm/boot/dts/lpc4337-ciaa.dts
index 7c16d639a1b4..beddaba85393 100644
--- a/arch/arm/boot/dts/lpc4337-ciaa.dts
+++ b/arch/arm/boot/dts/lpc4337-ciaa.dts
@@ -174,17 +174,17 @@
clock-frequency = <400000>;
eeprom@50 {
- compatible = "microchip,24c512";
+ compatible = "microchip,24c512", "atmel,24c512";
reg = <0x50>;
};
eeprom@51 {
- compatible = "microchip,24c02";
+ compatible = "microchip,24c02", "atmel,24c02";
reg = <0x51>;
};
eeprom@54 {
- compatible = "microchip,24c512";
+ compatible = "microchip,24c512", "atmel,24c512";
reg = <0x54>;
};
};
diff --git a/arch/arm/boot/dts/lpc4350-hitex-eval.dts b/arch/arm/boot/dts/lpc4350-hitex-eval.dts
index 874c75d44013..8b973f537d3a 100644
--- a/arch/arm/boot/dts/lpc4350-hitex-eval.dts
+++ b/arch/arm/boot/dts/lpc4350-hitex-eval.dts
@@ -429,7 +429,7 @@
};
eeprom@50 {
- compatible = "nxp,24c02";
+ compatible = "nxp,24c02", "atmel,24c02";
reg = <0x50>;
};
diff --git a/arch/arm/boot/dts/lpc4357-ea4357-devkit.dts b/arch/arm/boot/dts/lpc4357-ea4357-devkit.dts
index 9b5fad622522..02b23fa29d75 100644
--- a/arch/arm/boot/dts/lpc4357-ea4357-devkit.dts
+++ b/arch/arm/boot/dts/lpc4357-ea4357-devkit.dts
@@ -490,7 +490,7 @@
};
eeprom@57 {
- compatible = "microchip,24c64";
+ compatible = "microchip,24c64", "atmel,24c64";
reg = <0x57>;
};
};
--
2.9.3
^ permalink raw reply related
* [PATCH v3 08/21] ARM: dts: keystone: Add generic compatible string for I2C EEPROM
From: Javier Martinez Canillas @ 2017-04-14 1:04 UTC (permalink / raw)
To: linux-kernel
Cc: Mark Rutland, devicetree, Wolfram Sang, Russell King,
Javier Martinez Canillas, Rob Herring, Santosh Shilimkar,
linux-arm-kernel
In-Reply-To: <20170414010445.21727-1-javier@osg.samsung.com>
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@osg.samsung.com>
---
Changes in v3: None
Changes in v2: None
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 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/keystone-k2e-evm.dts b/arch/arm/boot/dts/keystone-k2e-evm.dts
index ae1ebe7ee021..8c79caae9c1b 100644
--- a/arch/arm/boot/dts/keystone-k2e-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2e-evm.dts
@@ -69,7 +69,7 @@
&i2c0 {
dtt@50 {
- compatible = "at,24c1024";
+ compatible = "at,24c1024", "atmel,24c1024";
reg = <0x50>;
};
};
diff --git a/arch/arm/boot/dts/keystone-k2hk-evm.dts b/arch/arm/boot/dts/keystone-k2hk-evm.dts
index 2156ff92d08f..7c6916a11b18 100644
--- a/arch/arm/boot/dts/keystone-k2hk-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2hk-evm.dts
@@ -145,7 +145,7 @@
&i2c0 {
dtt@50 {
- compatible = "at,24c1024";
+ compatible = "at,24c1024", "atmel,24c1024";
reg = <0x50>;
};
};
diff --git a/arch/arm/boot/dts/keystone-k2l-evm.dts b/arch/arm/boot/dts/keystone-k2l-evm.dts
index 056b42f99d7a..685a236a57f4 100644
--- a/arch/arm/boot/dts/keystone-k2l-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2l-evm.dts
@@ -42,7 +42,7 @@
&i2c0 {
dtt@50 {
- compatible = "at,24c1024";
+ compatible = "at,24c1024", "atmel,24c1024";
reg = <0x50>;
};
};
--
2.9.3
^ permalink raw reply related
* [PATCH v3 07/21] ARM: dts: imx: Add generic compatible string for I2C EEPROM
From: Javier Martinez Canillas @ 2017-04-14 1:04 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Wolfram Sang, Javier Martinez Canillas, Fabio Estevam,
devicetree-u79uwXL29TY76Z2rM5mHXA, Sascha Hauer, Rob Herring,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
Russell King, Shawn Guo
In-Reply-To: <20170414010445.21727-1-javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.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-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
---
Changes in v3: None
Changes in v2: None
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 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dtsi b/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dtsi
index 4f3e0f473581..e4c20b3a8ccd 100644
--- a/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dtsi
+++ b/arch/arm/boot/dts/imx27-phytec-phycard-s-som.dtsi
@@ -40,7 +40,7 @@
status = "okay";
at24@52 {
- compatible = "at,24c32";
+ compatible = "at,24c32", "atmel,24c32";
pagesize = <32>;
reg = <0x52>;
};
diff --git a/arch/arm/boot/dts/imx27-phytec-phycore-som.dtsi b/arch/arm/boot/dts/imx27-phytec-phycore-som.dtsi
index 82fec935ce83..e46a2fd55732 100644
--- a/arch/arm/boot/dts/imx27-phytec-phycore-som.dtsi
+++ b/arch/arm/boot/dts/imx27-phytec-phycore-som.dtsi
@@ -193,7 +193,7 @@
status = "okay";
at24@52 {
- compatible = "at,24c32";
+ compatible = "at,24c32", "atmel,24c32";
pagesize = <32>;
reg = <0x52>;
};
diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
index a5ba669b4eaa..55c1a6a7425d 100644
--- a/arch/arm/boot/dts/imx28-evk.dts
+++ b/arch/arm/boot/dts/imx28-evk.dts
@@ -203,7 +203,7 @@
};
at24@51 {
- compatible = "at24,24c32";
+ compatible = "at24,24c32", "atmel,24c32";
pagesize = <32>;
reg = <0x51>;
};
diff --git a/arch/arm/boot/dts/imx53-tqma53.dtsi b/arch/arm/boot/dts/imx53-tqma53.dtsi
index 85972f2201c2..95da69691de3 100644
--- a/arch/arm/boot/dts/imx53-tqma53.dtsi
+++ b/arch/arm/boot/dts/imx53-tqma53.dtsi
@@ -272,7 +272,7 @@
};
eeprom: 24c64@50 {
- compatible = "at,24c64";
+ compatible = "at,24c64", "atmel,24c64";
pagesize = <32>;
reg = <0x50>;
};
diff --git a/arch/arm/boot/dts/imx6q-cm-fx6.dts b/arch/arm/boot/dts/imx6q-cm-fx6.dts
index 66cac5328b86..9dda47a86552 100644
--- a/arch/arm/boot/dts/imx6q-cm-fx6.dts
+++ b/arch/arm/boot/dts/imx6q-cm-fx6.dts
@@ -215,7 +215,7 @@
clock-frequency = <100000>;
eeprom@50 {
- compatible = "at24,24c02";
+ compatible = "at24,24c02", "atmel,24c02";
reg = <0x50>;
pagesize = <16>;
};
diff --git a/arch/arm/boot/dts/imx6q-utilite-pro.dts b/arch/arm/boot/dts/imx6q-utilite-pro.dts
index 69bdd82ce21f..085080f61c7b 100644
--- a/arch/arm/boot/dts/imx6q-utilite-pro.dts
+++ b/arch/arm/boot/dts/imx6q-utilite-pro.dts
@@ -128,7 +128,7 @@
#size-cells = <0>;
eeprom@50 {
- compatible = "at24,24c02";
+ compatible = "at24,24c02", "atmel,24c02";
reg = <0x50>;
pagesize = <16>;
};
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v3 06/21] ARM: dts: efm32: Add generic compatible string for I2C EEPROM
From: Javier Martinez Canillas @ 2017-04-14 1:04 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Wolfram Sang, Javier Martinez Canillas,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Uwe Kleine-König, Mark Rutland, Russell King,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170414010445.21727-1-javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.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-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
---
Changes in v3: None
Changes in v2: None
arch/arm/boot/dts/efm32gg-dk3750.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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>;
};
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v3 05/21] ARM: dts: at91: Add generic compatible string for I2C EEPROM
From: Javier Martinez Canillas @ 2017-04-14 1:04 UTC (permalink / raw)
To: linux-kernel
Cc: Wolfram Sang, Javier Martinez Canillas, devicetree, Russell King,
Alexandre Belloni, Rob Herring, Nicolas Ferre, Peter Rosin,
Mark Rutland, linux-arm-kernel
In-Reply-To: <20170414010445.21727-1-javier@osg.samsung.com>
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@osg.samsung.com>
Acked-by: Peter Rosin <peda@axentia.se>
---
Changes in v3:
- Add Peter Rosin acked-by tag.
Changes in v2: None
arch/arm/boot/dts/at91-linea.dtsi | 2 +-
arch/arm/boot/dts/at91-tse850-3.dts | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/at91-linea.dtsi b/arch/arm/boot/dts/at91-linea.dtsi
index 0721c8472509..9bf9aaeff3e8 100644
--- a/arch/arm/boot/dts/at91-linea.dtsi
+++ b/arch/arm/boot/dts/at91-linea.dtsi
@@ -31,7 +31,7 @@
status = "okay";
eeprom@51 {
- compatible = "st,24c64";
+ compatible = "st,24c64", "atmel,24c64";
reg = <0x51>;
pagesize = <32>;
};
diff --git a/arch/arm/boot/dts/at91-tse850-3.dts b/arch/arm/boot/dts/at91-tse850-3.dts
index 7a68805a4eb5..e760e5982565 100644
--- a/arch/arm/boot/dts/at91-tse850-3.dts
+++ b/arch/arm/boot/dts/at91-tse850-3.dts
@@ -239,7 +239,7 @@
};
eeprom@50 {
- compatible = "nxp,24c02";
+ compatible = "nxp,24c02", "atmel,24c02";
reg = <0x50>;
pagesize = <16>;
};
--
2.9.3
^ permalink raw reply related
* [PATCH v3 04/21] ARM: dts: turris-omnia: Add generic compatible string for I2C EEPROM
From: Javier Martinez Canillas @ 2017-04-14 1:04 UTC (permalink / raw)
To: linux-kernel
Cc: Mark Rutland, devicetree, Jason Cooper, Wolfram Sang,
Russell King, Javier Martinez Canillas, Rob Herring, Andrew Lunn,
Gregory Clement, linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <20170414010445.21727-1-javier@osg.samsung.com>
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@osg.samsung.com>
---
Changes in v3: None
Changes in v2: None
arch/arm/boot/dts/armada-385-turris-omnia.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts b/arch/arm/boot/dts/armada-385-turris-omnia.dts
index 28eede180e4f..f24058737a13 100644
--- a/arch/arm/boot/dts/armada-385-turris-omnia.dts
+++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
@@ -171,7 +171,7 @@
/* leds device (in STM32F0) at address 0x2b */
eeprom@54 {
- compatible = "at,24c64";
+ compatible = "at,24c64", "atmel,24c64";
reg = <0x54>;
/* The EEPROM contains data for bootloader.
--
2.9.3
^ permalink raw reply related
* [PATCH v3 03/21] ARM: dts: omap: Add generic compatible string for I2C EEPROM
From: Javier Martinez Canillas @ 2017-04-14 1:04 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Wolfram Sang, Javier Martinez Canillas,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Benoît Cousson, devicetree-u79uwXL29TY76Z2rM5mHXA,
Rob Herring, Tony Lindgren, Mark Rutland,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Russell King, Mark Jackson
In-Reply-To: <20170414010445.21727-1-javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.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-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
---
Changes in v3: None
Changes in v2: None
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/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 +-
17 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-baltos.dtsi b/arch/arm/boot/dts/am335x-baltos.dtsi
index d42b98f15e8b..6ca780d0623f 100644
--- 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";
pagesize = <8>;
reg = <0x50>;
};
diff --git a/arch/arm/boot/dts/am335x-base0033.dts b/arch/arm/boot/dts/am335x-base0033.dts
index c2bee452dab8..062067251106 100644
--- a/arch/arm/boot/dts/am335x-base0033.dts
+++ b/arch/arm/boot/dts/am335x-base0033.dts
@@ -89,7 +89,7 @@
&i2c0 {
eeprom: eeprom@50 {
- compatible = "at,24c256";
+ compatible = "at,24c256", "atmel,24c256";
reg = <0x50>;
};
};
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi
index bf6b26abe35b..49c8c9409ce3 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -232,7 +232,7 @@
};
baseboard_eeprom: baseboard_eeprom@50 {
- compatible = "at,24c256";
+ compatible = "at,24c256", "atmel,24c256";
reg = <0x50>;
#address-cells = <1>;
@@ -251,7 +251,7 @@
clock-frequency = <100000>;
cape_eeprom0: cape_eeprom0@54 {
- compatible = "at,24c256";
+ compatible = "at,24c256", "atmel,24c256";
reg = <0x54>;
#address-cells = <1>;
#size-cells = <1>;
@@ -261,7 +261,7 @@
};
cape_eeprom1: cape_eeprom1@55 {
- compatible = "at,24c256";
+ compatible = "at,24c256", "atmel,24c256";
reg = <0x55>;
#address-cells = <1>;
#size-cells = <1>;
@@ -271,7 +271,7 @@
};
cape_eeprom2: cape_eeprom2@56 {
- compatible = "at,24c256";
+ compatible = "at,24c256", "atmel,24c256";
reg = <0x56>;
#address-cells = <1>;
#size-cells = <1>;
@@ -281,7 +281,7 @@
};
cape_eeprom3: cape_eeprom3@57 {
- compatible = "at,24c256";
+ compatible = "at,24c256", "atmel,24c256";
reg = <0x57>;
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm/boot/dts/am335x-nano.dts b/arch/arm/boot/dts/am335x-nano.dts
index 807494bc722b..946d7069f417 100644
--- a/arch/arm/boot/dts/am335x-nano.dts
+++ b/arch/arm/boot/dts/am335x-nano.dts
@@ -224,7 +224,7 @@
};
eeprom@53 {
- compatible = "microchip,24c02";
+ compatible = "microchip,24c02", "atmel,24c02";
reg = <0x53>;
pagesize = <8>;
};
diff --git a/arch/arm/boot/dts/am335x-pepper.dts b/arch/arm/boot/dts/am335x-pepper.dts
index 30e2f8770aaf..368cef158a19 100644
--- a/arch/arm/boot/dts/am335x-pepper.dts
+++ b/arch/arm/boot/dts/am335x-pepper.dts
@@ -67,7 +67,7 @@
};
eeprom: eeprom@50 {
- compatible = "at,24c256";
+ compatible = "at,24c256", "atmel,24c256";
reg = <0x50>;
};
diff --git a/arch/arm/boot/dts/am335x-shc.dts b/arch/arm/boot/dts/am335x-shc.dts
index bf8727a19ece..6a14b8478af0 100644
--- a/arch/arm/boot/dts/am335x-shc.dts
+++ b/arch/arm/boot/dts/am335x-shc.dts
@@ -188,7 +188,7 @@
};
at24@50 {
- compatible = "at24,24c32";
+ compatible = "at24,24c32", "atmel,24c32";
pagesize = <32>;
reg = <0x50>;
};
diff --git a/arch/arm/boot/dts/am335x-sl50.dts b/arch/arm/boot/dts/am335x-sl50.dts
index c5d2589c55fc..d03678de140c 100644
--- a/arch/arm/boot/dts/am335x-sl50.dts
+++ b/arch/arm/boot/dts/am335x-sl50.dts
@@ -309,7 +309,7 @@
};
eeprom: eeprom@50 {
- compatible = "at,24c256";
+ compatible = "at,24c256", "atmel,24c256";
reg = <0x50>;
};
diff --git a/arch/arm/boot/dts/am437x-idk-evm.dts b/arch/arm/boot/dts/am437x-idk-evm.dts
index c1f7f9336e64..6c831663a75f 100644
--- a/arch/arm/boot/dts/am437x-idk-evm.dts
+++ b/arch/arm/boot/dts/am437x-idk-evm.dts
@@ -339,7 +339,7 @@
clock-frequency = <400000>;
at24@50 {
- compatible = "at24,24c256";
+ compatible = "at24,24c256", "atmel,24c256";
pagesize = <64>;
reg = <0x50>;
};
diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts b/arch/arm/boot/dts/am437x-sk-evm.dts
index 4dc54bee2f36..1531b295336e 100644
--- a/arch/arm/boot/dts/am437x-sk-evm.dts
+++ b/arch/arm/boot/dts/am437x-sk-evm.dts
@@ -511,7 +511,7 @@
};
at24@50 {
- compatible = "at24,24c256";
+ compatible = "at24,24c256", "atmel,24c256";
pagesize = <64>;
reg = <0x50>;
};
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts b/arch/arm/boot/dts/am43x-epos-evm.dts
index 9acd4ccdec4e..ca9b11375298 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -477,7 +477,7 @@
};
at24@50 {
- compatible = "at24,24c256";
+ compatible = "at24,24c256", "atmel,24c256";
pagesize = <64>;
reg = <0x50>;
};
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
index 585d792a8fdd..6af022540300 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
+++ b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
@@ -388,7 +388,7 @@
};
eeprom: eeprom@50 {
- compatible = "at,24c32";
+ compatible = "at,24c32", "atmel,24c32";
reg = <0x50>;
};
};
diff --git a/arch/arm/boot/dts/omap3-cm-t3x.dtsi b/arch/arm/boot/dts/omap3-cm-t3x.dtsi
index 57b9a028a49a..d960f1b3b4b1 100644
--- a/arch/arm/boot/dts/omap3-cm-t3x.dtsi
+++ b/arch/arm/boot/dts/omap3-cm-t3x.dtsi
@@ -188,7 +188,7 @@
clock-frequency = <400000>;
at24@50 {
- compatible = "at24,24c02";
+ compatible = "at24,24c02", "atmel,24c02";
pagesize = <16>;
reg = <0x50>;
};
diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi
index b3a8b1f24499..430ab832783b 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -418,7 +418,7 @@
/* RFID EEPROM */
m24lr64@50 {
- compatible = "at,24c64";
+ compatible = "at,24c64", "atmel,24c64";
reg = <0x50>;
};
};
diff --git a/arch/arm/boot/dts/omap3-sb-t35.dtsi b/arch/arm/boot/dts/omap3-sb-t35.dtsi
index 73643fabde5d..e54091fbd40b 100644
--- a/arch/arm/boot/dts/omap3-sb-t35.dtsi
+++ b/arch/arm/boot/dts/omap3-sb-t35.dtsi
@@ -90,7 +90,7 @@
clock-frequency = <400000>;
at24@50 {
- compatible = "at24,24c02";
+ compatible = "at24,24c02", "atmel,24c02";
pagesize = <16>;
reg = <0x50>;
};
diff --git a/arch/arm/boot/dts/omap4-var-som-om44.dtsi b/arch/arm/boot/dts/omap4-var-som-om44.dtsi
index 758b6eb7ae43..6500bfc8d130 100644
--- a/arch/arm/boot/dts/omap4-var-som-om44.dtsi
+++ b/arch/arm/boot/dts/omap4-var-som-om44.dtsi
@@ -241,7 +241,7 @@
};
eeprom@50 {
- compatible = "microchip,24c32";
+ compatible = "microchip,24c32", "atmel,24c32";
reg = <0x50>;
};
};
diff --git a/arch/arm/boot/dts/omap5-cm-t54.dts b/arch/arm/boot/dts/omap5-cm-t54.dts
index b153f604932a..e0e31bfbf0e0 100644
--- a/arch/arm/boot/dts/omap5-cm-t54.dts
+++ b/arch/arm/boot/dts/omap5-cm-t54.dts
@@ -404,7 +404,7 @@
clock-frequency = <400000>;
at24@50 {
- compatible = "at24,24c02";
+ compatible = "at24,24c02", "atmel,24c02";
pagesize = <16>;
reg = <0x50>;
};
diff --git a/arch/arm/boot/dts/omap5-sbc-t54.dts b/arch/arm/boot/dts/omap5-sbc-t54.dts
index 337bbbc01a35..efc70f80abae 100644
--- a/arch/arm/boot/dts/omap5-sbc-t54.dts
+++ b/arch/arm/boot/dts/omap5-sbc-t54.dts
@@ -44,7 +44,7 @@
clock-frequency = <400000>;
at24@50 {
- compatible = "at24,24c02";
+ compatible = "at24,24c02", "atmel,24c02";
pagesize = <16>;
reg = <0x50>;
};
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v3 01/21] dt-bindings: i2c: eeprom: Document manufacturer used as generic fallback
From: Javier Martinez Canillas @ 2017-04-14 1:04 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Wolfram Sang, Javier Martinez Canillas, Simon Horman,
devicetree-u79uwXL29TY76Z2rM5mHXA, Sekhar Nori, David Lechner,
Alexandre Belloni, Rob Herring, Mark Rutland
In-Reply-To: <20170414010445.21727-1-javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.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.
Document in the Device Tree binding document that this manufacturer should
be used as the generic fallback.
Suggested-by: Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>
Signed-off-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
---
Changes in v3: None
Changes in v2: None
Documentation/devicetree/bindings/eeprom/eeprom.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt b/Documentation/devicetree/bindings/eeprom/eeprom.txt
index 5696eb508e95..d0395f14e2b3 100644
--- a/Documentation/devicetree/bindings/eeprom/eeprom.txt
+++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
@@ -17,7 +17,8 @@ Required properties:
"renesas,r1ex24002"
If there is no specific driver for <manufacturer>, a generic
- driver based on <type> is selected. Possible types are:
+ driver based on <type> and manufacturer "atmel" is selected.
+ Possible types are:
"24c00", "24c01", "24c02", "24c04", "24c08", "24c16", "24c32", "24c64",
"24c128", "24c256", "24c512", "24c1024", "spd"
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v3 00/21] eeprom: at24: Add OF device ID table
From: Javier Martinez Canillas @ 2017-04-14 1:04 UTC (permalink / raw)
To: linux-kernel
Cc: Mark Rutland, Andrew Lunn, Wolfram Sang, Tony Lindgren,
Catalin Marinas, Will Deacon, Russell King, Masahiro Yamada,
Alexandre Belloni, linux-i2c, Hongtao Jia, Mark Jackson,
Herbert Xu, Horia Geantă, Michael Ellerman, Magnus Damm,
Michal Simek, Javier Martinez Canillas, Andy Shevchenko,
linux-arm-kernel, Benjamin Herrenschmidt, Jason Cooper
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.
The first patch adds the OF device ID table for the at24 driver and the
next patches adds a generic fallback compatible string to each DTS that
defines a compatible I2C EEPROM device node.
Patches can be applied independently since the DTS change without the
driver change is a no-op and the OF device 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 v3:
- Fix wrong .data values for "atmel,24c02" and "atmel,24c64" entries.
- Add Peter Rosin acked-by tag.
- 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 (21):
dt-bindings: i2c: eeprom: Document manufacturer used as generic
fallback
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: at91: 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 | 3 +-
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/at91-linea.dtsi | 2 +-
arch/arm/boot/dts/at91-tse850-3.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 | 2 +-
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 +++++++++++++++++++++-
68 files changed, 158 insertions(+), 94 deletions(-)
--
2.9.3
^ permalink raw reply
* Re: [RFC 1/2] dt-bindings: add mmio-based syscon mux controller DT bindings
From: Steve Longerbeam @ 2017-04-14 1:03 UTC (permalink / raw)
To: Philipp Zabel, Peter Rosin
Cc: Rob Herring, Mark Rutland, Sakari Ailus,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ
In-Reply-To: <20170413154812.19597-1-p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On 04/13/2017 08:48 AM, Philipp Zabel wrote:
> This adds device tree binding documentation for mmio-based syscon
> multiplexers controlled by a single bitfield in a syscon register
> range.
Nice! (you beat me to it, I was about to embark on this myself :)
Looks good to me, just some minor comments below.
>
> Signed-off-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> ---
> Documentation/devicetree/bindings/mux/mmio-mux.txt | 56 ++++++++++++++++++++++
> 1 file changed, 56 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mux/mmio-mux.txt
>
> diff --git a/Documentation/devicetree/bindings/mux/mmio-mux.txt b/Documentation/devicetree/bindings/mux/mmio-mux.txt
> new file mode 100644
> index 0000000000000..11d96f5d98583
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mux/mmio-mux.txt
> @@ -0,0 +1,56 @@
> +MMIO bitfield-based multiplexer controller bindings
> +
> +Define a syscon bitfield to be used to control a multiplexer. The parent
I think "Define a register bitfield to be used ..." is more clear.
> +device tree node must be a syscon node to provide register access.
> +
> +Required properties:
> +- compatible : "gpio-mux"
Er, "mmio-mux"
> +- reg : register base of the register containing the control bitfield
> +- bit-mask : bitmask of the control bitfield in the control register
> +- bit-shift : bit offset of the control bitfield in the control register
> +- #mux-control-cells : <0>
> +* Standard mux-controller bindings as decribed in mux-controller.txt
> +
> +Optional properties:
> +- idle-state : if present, the state the mux will have when idle. The
> + special state MUX_IDLE_AS_IS is the default.
> +
> +The multiplexer state is defined as the value of the bitfield described
> +by the reg, bit-mask, and bit-shift properties, accessed through the parent
> +syscon.
> +
> +Example:
> +
> + syscon {
> + compatible = "syscon";
> +
> + mux: mux-controller@3 {
> + compatible = "mmio-mux";
> + reg = <0x3>;
> + bit-mask = <0x1>;
> + bit-shift = <5>;
> + #mux-control-cells = <0>;
> + };
> + };
> +
> + video-mux {
I like this as an example consumer of a mmio-mux, but just
the same some might argue this doesn't really fit here.
Steve
> + compatible = "video-mux";
> + mux-controls = <&mux>;
> +
> + ports {
> + /* input 0 */
> + port@0 {
> + reg = <0>;
> + };
> +
> + /* input 1 */
> + port@1 {
> + reg = <1>;
> + };
> +
> + /* output */
> + port@2 {
> + reg = <2>;
> + };
> + };
> + };
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v11 01/10] devicetree: power: Add battery.txt
From: Sebastian Reichel @ 2017-04-14 0:33 UTC (permalink / raw)
To: Liam Breck
Cc: Rob Herring, Andrew F. Davis, linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Tony Lindgren
In-Reply-To: <CAKvHMgTxRJXgfpDgqQ_+=ErFEZAh9CodjVn5ZOoCfqPqSZWetA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 4789 bytes --]
Hi,
On Fri, Apr 07, 2017 at 12:23:29PM -0700, Liam Breck wrote:
> [+CC Tony Lindgren]
>
> Rob & Sebastian & Tony & Andrew,
>
> With this binding we allow a DT to hard-code battery characteristics.
> But mainline dts files for boards & boxes really should NOT include
> immutable battery properties unless the battery is inseparable from
> the electronics. We want to prevent unpredictable behavior due to
> incorrect DT properties after a user changes a battery to a different
> type.
>
> It's OK for device vendors to hard-code battery characteristics in DT,
> but mainline dts is another matter.
>
> If this is agreed, how should we document it?
That's not a problem of mainline vs vendor. The binding may only be
used for batteries, that cannot be exchanged with a different type.
That's why I originally suggested the "fixed-battery" name. IMHO
it would be ok to use the binding also for DTS files distributed
with the mainline kernel as long as the described device provides
some kind of protection against using batteries of a different type.
For example I would feel ok adding a simple-battery node for the
Droid 4 (which probably does not need one), since the battery has
a custom form-factor, is screwed to the device and has a custom
connector. So while it can be replaced, the new battery would have
the same technical specs.
I suggest to add something similar as the following to the binding:
Using incorrect battery parameters is a SAFETY HAZARD - If used
incorrectly, Lithium based batteries can explode. You should be
really sure, that all provided values are correct. Also if the
battery in your device can be replaced with a different battery
(without major hacks), you may not use this binding for safety
reasons.
-- Sebastian
> On Mon, Mar 20, 2017 at 2:43 AM, Liam Breck <liam-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn@public.gmane.org> wrote:
> > From: Liam Breck <kernel-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn@public.gmane.org>
> >
> > Documentation of static battery characteristics that can be defined
> > for batteries which cannot self-identify. This information is required
> > by fuel-gauge and charger chips for proper handling of the battery.
> >
> > Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > Signed-off-by: Matt Ranostay <matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org>
> > Signed-off-by: Liam Breck <kernel-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn@public.gmane.org>
> > ---
> > .../devicetree/bindings/power/supply/battery.txt | 43 ++++++++++++++++++++++
> > 1 file changed, 43 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/power/supply/battery.txt
> >
> > diff --git a/Documentation/devicetree/bindings/power/supply/battery.txt b/Documentation/devicetree/bindings/power/supply/battery.txt
> > new file mode 100644
> > index 0000000..53a68c0
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/power/supply/battery.txt
> > @@ -0,0 +1,43 @@
> > +Battery Characteristics
> > +
> > +The devicetree battery node provides static battery characteristics.
> > +In smart batteries, these are typically stored in non-volatile memory
> > +on a fuel gauge chip. The battery node should be used where there is
> > +no appropriate non-volatile memory, or it is unprogrammed/incorrect.
> > +
> > +Required Properties:
> > + - compatible: Must be "simple-battery"
> > +
> > +Optional Properties:
> > + - voltage-min-design-microvolt: drained battery voltage
> > + - energy-full-design-microwatt-hours: battery design energy
> > + - charge-full-design-microamp-hours: battery design capacity
> > +
> > +Battery properties are named, where possible, for the corresponding
> > +elements in enum power_supply_property, defined in
> > +https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/power_supply.h#n86
> > +
> > +Batteries must be referenced by chargers and/or fuel-gauges
> > +using a phandle. The phandle's property should be named
> > +"monitored-battery".
> > +
> > +Example:
> > +
> > + bat: battery {
> > + compatible = "simple-battery";
> > + voltage-min-design-microvolt = <3200000>;
> > + energy-full-design-microwatt-hours = <5290000>;
> > + charge-full-design-microamp-hours = <1430000>;
> > + };
> > +
> > + charger: charger@11 {
> > + ....
> > + monitored-battery = <&bat>;
> > + ...
> > + };
> > +
> > + fuel_gauge: fuel-gauge@22 {
> > + ....
> > + monitored-battery = <&bat>;
> > + ...
> > + };
> > --
> > 2.9.3
> >
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 05/22] ARM: dts: at91: Add generic compatible string for I2C EEPROM
From: Simon Horman @ 2017-04-13 23:58 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Javier Martinez Canillas, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Wolfram Sang, Russell King,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Geert Uytterhoeven, Peter Rosin,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170413212059.unh2mfo2w4oc4t33-m++hUPXGwpdeoWH0uzbU5w@public.gmane.org>
On Thu, Apr 13, 2017 at 11:20:59PM +0200, Alexandre Belloni wrote:
> On 13/04/2017 at 18:09:56 -0300, Javier Martinez Canillas wrote:
> > Hello Peter,
> >
> > On 04/13/2017 05:43 PM, Peter Rosin wrote:
> > > On 2017-04-13 20:28, Javier Martinez Canillas wrote:
> >
> > [snip]
> >
> > >>
> > >> eeprom@50 {
> > >> - compatible = "nxp,24c02";
> > >> + compatible = "nxp,24c02","atmel,24c02";
> > >> reg = <0x50>;
> > >> pagesize = <16>;
> > >> };
> > >>
> > >
> > > Sure, in principle. But not having a space after the commas is a real OCD
> > > trigger for me. My spine is rotating... :-)
> > >
> >
> > Right, Geert already pointed out. It's something I missed in my sed script
> > so I got it wrong in all the DTS :(
> >
> > I'll fix my script and send a v2.
> >
>
> That would be v3, right? ;)
>
> > > Anyway, with those whitespace fixes (and without them too, but please):
> > > Acked-by: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
> > >
> >
> > Thanks for the review!
> >
>
> I'd like to be copied on the first patches to ensure they are applied
> before applying that one. (Also, it is probably too late for 4.12 anyway
> because we are past rc6).
Ditto
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 05/22] ARM: dts: at91: Add generic compatible string for I2C EEPROM
From: Javier Martinez Canillas @ 2017-04-13 23:46 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Peter Rosin, linux-kernel, Wolfram Sang, devicetree, Russell King,
Rob Herring, Nicolas Ferre, Mark Rutland, linux-arm-kernel,
Geert Uytterhoeven
In-Reply-To: <20170413212059.unh2mfo2w4oc4t33@piout.net>
Hello Alexandre,
On 04/13/2017 06:20 PM, Alexandre Belloni wrote:
> On 13/04/2017 at 18:09:56 -0300, Javier Martinez Canillas wrote:
>> Hello Peter,
>>
>> On 04/13/2017 05:43 PM, Peter Rosin wrote:
>>> On 2017-04-13 20:28, Javier Martinez Canillas wrote:
>>
>> [snip]
>>
>>>>
>>>> eeprom@50 {
>>>> - compatible = "nxp,24c02";
>>>> + compatible = "nxp,24c02","atmel,24c02";
>>>> reg = <0x50>;
>>>> pagesize = <16>;
>>>> };
>>>>
>>>
>>> Sure, in principle. But not having a space after the commas is a real OCD
>>> trigger for me. My spine is rotating... :-)
>>>
>>
>> Right, Geert already pointed out. It's something I missed in my sed script
>> so I got it wrong in all the DTS :(
>>
>> I'll fix my script and send a v2.
>>
>
> That would be v3, right? ;)
>
err, right :)
>>> Anyway, with those whitespace fixes (and without them too, but please):
>>> Acked-by: Peter Rosin <peda@axentia.se>
>>>
>>
>> Thanks for the review!
>>
>
> I'd like to be copied on the first patches to ensure they are applied
> before applying that one. (Also, it is probably too late for 4.12 anyway
Ok, I'll copy you on the whole patch-set. But keep in mind that there is
no strict order since $SUBJECT without the at24 OF table is a no-op (the
match happens between first device in compatible string and I2C table).
> because we are past rc6).
>
Yes, there's no rush on applying these. I'm just posting all the patches
needed to finally have a proper OF modalias reporting in the I2C core.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* Re: [RFC net-next] of: mdio: Honor hints from MDIO bus drivers
From: Florian Fainelli @ 2017-04-13 23:20 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
Rob Herring, Frank Rowand,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, open list
In-Reply-To: <20170413215114.GB29708-g2DYL2Zd6BY@public.gmane.org>
On 04/13/2017 02:51 PM, Andrew Lunn wrote:
>> The DT binding is in tree and provides an example of how the switch
>> looks like, below is the example, but I am also adding the MDIO bus and
>> the PHYs just so you can see how things wind up:
>>
>> switch_top@f0b00000 {
>> compatible = "simple-bus";
>> #size-cells = <1>;
>> #address-cells = <1>;
>> ranges = <0 0xf0b00000 0x40804>;
>>
>> ethernet_switch@0 {
>> compatible = "brcm,bcm7445-switch-v4.0";
>> #size-cells = <0>;
>> #address-cells = <1>;
>> reg = <0x0 0x40000
>> 0x40000 0x110
>> 0x40340 0x30
>> 0x40380 0x30
>> 0x40400 0x34
>> 0x40600 0x208>;
>> reg-names = "core", "reg", intrl2_0", "intrl2_1",
>> "fcb, "acb";
>> interrupts = <0 0x18 0
>> 0 0x19 0>;
>> brcm,num-gphy = <1>;
>> brcm,num-rgmii-ports = <2>;
>> brcm,fcb-pause-override;
>> brcm,acb-packets-inflight;
>>
>> ports {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> port@0 {
>> label = "gphy";
>> reg = <0>;
>> phy-handle = <&phy5>;
>> };
>>
>> sw0port1: port@1 {
>> label = "rgmii_1";
>> reg = <1>;
>> phy-mode = "rgmii";
>> fixed-link {
>> speed = <1000>;
>> full-duplex;
>> };
>> }
>> };
>> };
>>
>> mdio@403c0 {
>> reg = <0x403c0 0x8 0x40300 0x18>;
>> #address-cells = <0x1>;
>> #size-cells = <0x0>;
>> compatible = "brcm,unimac-mdio";
>> reg-names = "mdio", "mdio_indir_rw";
>>
>> switch: switch@0 {
>> broken-turn-around;
>> reg = <0x0>;
>> compatible = "brcm,bcm53125";
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> ports {
>> ..
>> port@8 {
>> ethernet = <&sw0port1>;
>> };
>> ...
>> };
>> };
>>
>> phy5: ethernet-phy@5 {
>> reg = <0x5>;
>> compatible = "ethernet-phy-ieee802.3-c22";
>> };
>> };
>> };
>
> So phy5 is connected to the internal switch with a phy-handle. But
> because of your double usage of this node, it also can be mapped into
> the external switches port 5?
>
> Is that your problem?
Kind of, it does translate into an invalid mapping by virtue of the PHY
being in a bad state, see below.
The mapping per-se is not the problem, but the fact that the PHY driver
is probed twice is the original problem that I have. The double probing
comes from the switch driver being probed first (drivers/net/dsa/ comes
before drivers/net/ethernet) and depends on the master netdev to be running.
We need to turn on the Gigabit PHY clock in order to be able to read its
PHY OUI and map it to a driver (yes a workaround could be to put its
exact compatible string in DT, that way, no need for get_phy_id()). We
have a local change in mdio-bcm-unimac.c which does exactly that (using
the clock framework), and then, to avoid artificially bumping the clock
reference count, the BCM7xxx PHY driver in its ->probe() function checks
whether the clock is enabled (yes, using __clk_is_enabled while it
probably should not) and keep the clock turned on for the MDIO layer to
successfully read/write from the PHY. The BCM7xxx PHY driver does
properly manage the clock though, and turns it off upon ->remove(). We
got probed and removed once, no more clock enabled because of the first
probe deferral.
The second time around, when the slave MII bus probes us again, we go
through the BCM7xxx ->probe() and ->remove() callbacks again, but the
clock was already turned off due to first probe that got deferred.
When the bcm_sf2 driver finally gets initialized, we try to attach to
this Gigabit PHY, the driver is there, good, but the clock is turned off
already, so the PHY does not respond correctly at all anymore and we
end-up reading garbage.
>
> It seems like you should add an mdio node inside your switch node, and
> list your external switch internal/external phys there if needed.
I think I am going to keep this hack local and think about solving this
differently on an upstream kernel, since I am convinced now this is not
necessarily the right approach.
Thanks for your time and consideration!
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv4 0/2] Nokia H4+ support
From: Sebastian Reichel @ 2017-04-13 23:19 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Gustavo F. Padovan, Johan Hedberg, Rob Herring, Pavel Machek,
Linux Bluetooth, devicetree, linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <3CE124E5-09B7-423D-B979-73564EB3BC6C-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 649 bytes --]
Hi Marcel,
On Thu, Apr 13, 2017 at 10:33:58AM +0200, Marcel Holtmann wrote:
> > Here is the fourth revision of the nokia bluetooth patchset. Compared
> > to the previous one the following things have changed:
> >
> > * Drop patch 1-8 (applied by Marcel) and update Cc/To for patchset
> > * Order includes in the driver alphabetically
> > * Explicitly include <linux/of.h> in the nokia bluetooth driver
> >
> > -- Sebastian
> >
> > Sebastian Reichel (2):
> > dt-bindings: net: bluetooth: Add nokia-bluetooth
> > Bluetooth: add nokia driver
>
> both patches have been applied to bluetooth-next tree.
Thanks.
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] mfd: cros-ec: Add functions to read mapped memory
From: Moritz Fischer @ 2017-04-13 22:53 UTC (permalink / raw)
To: Guenter Roeck
Cc: Moritz Fischer, linux-hwmon, Linux Kernel Mailing List,
Devicetree List, Lee Jones, olof, jdelvare, Rob Herring,
Mark Rutland
In-Reply-To: <20170413210354.GA17134@roeck-us.net>
Hi Guenter,
On Thu, Apr 13, 2017 at 2:03 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> On Fri, Apr 07, 2017 at 03:00:08PM -0700, Moritz Fischer wrote:
>> From: Moritz Fischer <mdf@kernel.org>
>>
>> The ChromeOS EC has mapped memory regions where things like temperature
>> sensors and fan speed are stored. Provide access to those from the
>> cros-ec mfd device.
>>
>
> Turns out struct cros_ec_device already provides a cmd_readmem callback,
> which is widely used by other drivers. Why don't you just use it ?
This is only actually set by the lpc version of the cros_ec. I2C and
SPI connected ECs
emulate it. I can most certainly hook it up in the (spi,i2c) drivers,
but the implementation
for SPI and I2C needs to live somewhere. drivers/platform/chrome/cros_ec_proto.c
seemed to be a good place.
Thanks for the feedback!
Moritz
^ permalink raw reply
* Re: [PATCH 8/8] ARM: dts: imx7d-sdb: Enable PCIe peripheral
From: Fabio Estevam @ 2017-04-13 22:23 UTC (permalink / raw)
To: Andrey Smirnov
Cc: Shawn Guo, yurovsky-Re5JQEeQqe8AvxtiuMwx3w, Sascha Hauer,
Fabio Estevam, Rob Herring, Mark Rutland, Russell King,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <20170413133242.5068-9-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, Apr 13, 2017 at 10:32 AM, Andrey Smirnov
<andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> +&pcie {
> + pinctrl-names = "default";
> + reset-gpio = <&gpio_spi 1 GPIO_ACTIVE_LOW>;
> + disable-gpio = <&gpio_spi 0 GPIO_ACTIVE_LOW>;
I don't see this property in linux-next.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 6/8] ARM: dts: imx7d-sdb: Add GPIO expander node
From: Fabio Estevam @ 2017-04-13 22:20 UTC (permalink / raw)
To: Andrey Smirnov
Cc: Shawn Guo, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Russell King,
linux-kernel, Rob Herring, Sascha Hauer, Fabio Estevam,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
yurovsky-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <20170413133242.5068-7-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Andrey,
On Thu, Apr 13, 2017 at 10:32 AM, Andrey Smirnov
<andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
> index 5be01a1..e0ff276 100644
> --- a/arch/arm/boot/dts/imx7d-sdb.dts
> +++ b/arch/arm/boot/dts/imx7d-sdb.dts
> @@ -52,6 +52,30 @@
> reg = <0x80000000 0x80000000>;
> };
>
> + spi4 {
Here you use spi4 label...
> + compatible = "spi-gpio";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_spi1>;
and here spi1, which is a bit confusing.
> + status = "okay";
> + gpio-sck = <&gpio1 13 0>;
> + gpio-mosi = <&gpio1 9 0>;
> + cs-gpios = <&gpio1 12 0>;
You could use GPIO_ACTIVE_HIGH flag for better readability.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 4/8] ARM: dts: imx7s: Add node for GPC
From: Fabio Estevam @ 2017-04-13 22:00 UTC (permalink / raw)
To: Tyler Baker
Cc: Andrey Smirnov, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Russell King,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
Sascha Hauer, Fabio Estevam, Shawn Guo, linux-arm-kernel,
yurovsky-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <CANMBJr4mci5LyuBNT50dupxSVz+t-5mhWv8a7LBvY4MgupomVQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Apr 13, 2017 at 6:35 PM, Tyler Baker <tyler.baker-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> The following patch fixes the backtrace on my board. I'll submit this
> patch in a moment.
>
> From: Tyler Baker <tyler.baker-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Date: Thu, 13 Apr 2017 14:29:49 -0700
> Subject: [PATCH] irqchip/irq-imx-gpcv2: fix spinlock initialization
>
> Call raw_spin_lock_init() before the spinlocks are used to prevent a
> lockdep splat.
>
> Signed-off-by: Tyler Baker <tyler.baker-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Yes, it makes sense:
Reviewed-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC net-next] of: mdio: Honor hints from MDIO bus drivers
From: Andrew Lunn @ 2017-04-13 21:51 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, davem, Rob Herring, Frank Rowand,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, open list
In-Reply-To: <6fdcec91-829b-70c9-8780-992b67f6831a@gmail.com>
> The DT binding is in tree and provides an example of how the switch
> looks like, below is the example, but I am also adding the MDIO bus and
> the PHYs just so you can see how things wind up:
>
> switch_top@f0b00000 {
> compatible = "simple-bus";
> #size-cells = <1>;
> #address-cells = <1>;
> ranges = <0 0xf0b00000 0x40804>;
>
> ethernet_switch@0 {
> compatible = "brcm,bcm7445-switch-v4.0";
> #size-cells = <0>;
> #address-cells = <1>;
> reg = <0x0 0x40000
> 0x40000 0x110
> 0x40340 0x30
> 0x40380 0x30
> 0x40400 0x34
> 0x40600 0x208>;
> reg-names = "core", "reg", intrl2_0", "intrl2_1",
> "fcb, "acb";
> interrupts = <0 0x18 0
> 0 0x19 0>;
> brcm,num-gphy = <1>;
> brcm,num-rgmii-ports = <2>;
> brcm,fcb-pause-override;
> brcm,acb-packets-inflight;
>
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
>
> port@0 {
> label = "gphy";
> reg = <0>;
> phy-handle = <&phy5>;
> };
>
> sw0port1: port@1 {
> label = "rgmii_1";
> reg = <1>;
> phy-mode = "rgmii";
> fixed-link {
> speed = <1000>;
> full-duplex;
> };
> }
> };
> };
>
> mdio@403c0 {
> reg = <0x403c0 0x8 0x40300 0x18>;
> #address-cells = <0x1>;
> #size-cells = <0x0>;
> compatible = "brcm,unimac-mdio";
> reg-names = "mdio", "mdio_indir_rw";
>
> switch: switch@0 {
> broken-turn-around;
> reg = <0x0>;
> compatible = "brcm,bcm53125";
> #address-cells = <1>;
> #size-cells = <0>;
>
> ports {
> ..
> port@8 {
> ethernet = <&sw0port1>;
> };
> ...
> };
> };
>
> phy5: ethernet-phy@5 {
> reg = <0x5>;
> compatible = "ethernet-phy-ieee802.3-c22";
> };
> };
> };
So phy5 is connected to the internal switch with a phy-handle. But
because of your double usage of this node, it also can be mapped into
the external switches port 5?
Is that your problem?
It seems like you should add an mdio node inside your switch node, and
list your external switch internal/external phys there if needed.
Andrew
^ permalink raw reply
* Re: [PATCH 4/8] ARM: dts: imx7s: Add node for GPC
From: Tyler Baker @ 2017-04-13 21:35 UTC (permalink / raw)
To: Fabio Estevam
Cc: Andrey Smirnov, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Russell King,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
Sascha Hauer, Fabio Estevam, Shawn Guo, linux-arm-kernel,
yurovsky-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <CAOMZO5BjzSJws7zjJ5+aZkfeF+15twEu9zS3V+g6wQrtUiNyqQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 13 April 2017 at 13:49, Fabio Estevam <festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Thu, Apr 13, 2017 at 5:13 PM, Tyler Baker <tyler.baker-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>
>> I've rebased this series on the next-20170413 for sanity sake, and
>> realized there doesn't appear to be a way to select CONFIG_IMX_GPCV2.
>> I forced it using 'default y' and configured with imx_v6_v7_defconfig.
>> Now my board is booting. Before this series is applied, it may be good
>> to have CONFIG_IMX_GPCV2 selected specifically for iMX7 platform,
>> otherwise there will be boot regressions.
>
> Something like this?
>
> diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
> index f03ef43..fe99a48 100644
> --- a/drivers/irqchip/Kconfig
> +++ b/drivers/irqchip/Kconfig
> @@ -253,6 +253,7 @@ config RENESAS_H8S_INTC
>
> config IMX_GPCV2
> bool
> + def_bool y if SOC_IMX7D
> select IRQ_DOMAIN
> help
> Enables the wakeup IRQs for IMX platforms with GPCv2 block
Exactly. LGTM.
>> I'd encounter a backtrace with next-20170413 + imx_v6_v7_defconfig +
>> CONFIG_IMX_GPCV2=y
>>
>> Backtrace:
>> [<c010c364>] (dump_backtrace) from [<c010c610>] (show_stack+0x18/0x1c)
>
> but prior to fixing the Kconfig we need to fix this backtrace you reported.
I dug into this a bit, and lockdep is unhappy about spin locks not
being initialized before use.
The following patch fixes the backtrace on my board. I'll submit this
patch in a moment.
From: Tyler Baker <tyler.baker-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Date: Thu, 13 Apr 2017 14:29:49 -0700
Subject: [PATCH] irqchip/irq-imx-gpcv2: fix spinlock initialization
Call raw_spin_lock_init() before the spinlocks are used to prevent a
lockdep splat.
Signed-off-by: Tyler Baker <tyler.baker-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
drivers/irqchip/irq-imx-gpcv2.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/irqchip/irq-imx-gpcv2.c b/drivers/irqchip/irq-imx-gpcv2.c
index e13236f..9463f35 100644
--- a/drivers/irqchip/irq-imx-gpcv2.c
+++ b/drivers/irqchip/irq-imx-gpcv2.c
@@ -230,6 +230,8 @@ static int __init imx_gpcv2_irqchip_init(struct
device_node *node,
return -ENOMEM;
}
+ raw_spin_lock_init(&cd->rlock);
+
cd->gpc_base = of_iomap(node, 0);
if (!cd->gpc_base) {
pr_err("fsl-gpcv2: unable to map gpc registers\n");
--
2.9.3
Cheers,
Tyler
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 3/3] hwmon: cros-ec-hwmon: Add Chromium-EC HWMON driver
From: Guenter Roeck @ 2017-04-13 21:34 UTC (permalink / raw)
To: Moritz Fischer
Cc: linux-hwmon, linux-kernel, devicetree, lee.jones, olof, jdelvare,
robh+dt, mark.rutland, Moritz Fischer
In-Reply-To: <1491602410-31518-3-git-send-email-moritz.fischer@ettus.com>
On Fri, Apr 07, 2017 at 03:00:10PM -0700, Moritz Fischer wrote:
> From: Moritz Fischer <mdf@kernel.org>
>
> This adds a hwmon driver for the Chromium EC's fans
> and temperature sensors.
>
> Signed-off-by: Moritz Fischer <mdf@kernel.org>
> ---
>
> This one still needs some work, but I figured some early feedback might not hurt.
> Specifically I was wondering if using the devm_hwmon_register_with_info() is
> preferable to the devm_hwmon_register_with_groups().
>
Please use devm_hwmon_register_with_info().
> The EC has a bunch of additional features such as setting thermal limits etc,
> which I'd still like to add but I figured I'll get some feedback on what I got so far.
>
Those would probably be more appropriate for a thermal driver.
> Thanks,
>
> Moritz
>
> ---
> drivers/hwmon/Kconfig | 8 ++
> drivers/hwmon/Makefile | 1 +
> drivers/hwmon/cros-ec-hwmon.c | 244 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 253 insertions(+)
> create mode 100644 drivers/hwmon/cros-ec-hwmon.c
>
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 0649d53f3..3b9155f 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -1254,6 +1254,14 @@ config SENSORS_PCF8591
> These devices are hard to detect and rarely found on mainstream
> hardware. If unsure, say N.
>
> +config SENSORS_CROS_EC
> + tristate "ChromeOS EC hwmon"
> + depends on MFD_CROS_EC
> + help
> + If you say yes here you get hwmon support that will expose the
> + ChromeOS internal sensors for fanspeed and temperature to the
> + Linux hwmon subsystem.
> +
> source drivers/hwmon/pmbus/Kconfig
>
> config SENSORS_PWM_FAN
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index 5509edf..e59b5da 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -134,6 +134,7 @@ obj-$(CONFIG_SENSORS_PC87360) += pc87360.o
> obj-$(CONFIG_SENSORS_PC87427) += pc87427.o
> obj-$(CONFIG_SENSORS_PCF8591) += pcf8591.o
> obj-$(CONFIG_SENSORS_POWR1220) += powr1220.o
> +obj-$(CONFIG_SENSORS_CROS_EC) += cros-ec-hwmon.o
> obj-$(CONFIG_SENSORS_PWM_FAN) += pwm-fan.o
> obj-$(CONFIG_SENSORS_S3C) += s3c-hwmon.o
> obj-$(CONFIG_SENSORS_SCH56XX_COMMON)+= sch56xx-common.o
> diff --git a/drivers/hwmon/cros-ec-hwmon.c b/drivers/hwmon/cros-ec-hwmon.c
> new file mode 100644
> index 0000000..29d8b06
> --- /dev/null
> +++ b/drivers/hwmon/cros-ec-hwmon.c
> @@ -0,0 +1,244 @@
> +/*
> + * Copyright (c) 2017, National Instruments Corp.
> + *
> + * Chromium EC Fan speed and temperature sensor driver
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/device.h>
> +#include <linux/kernel.h>
> +#include <linux/slab.h>
> +#include <linux/sysfs.h>
> +#include <linux/spi/spi.h>
> +#include <linux/module.h>
> +#include <linux/err.h>
> +#include <linux/of_platform.h>
> +#include <linux/hwmon.h>
> +#include <linux/hwmon-sysfs.h>
> +#include <linux/bitops.h>
> +#include <linux/mfd/cros_ec.h>
> +
> +struct cros_ec_hwmon_priv {
> + struct cros_ec_device *ec;
> + struct device *hwmon_dev;
> +
> + struct attribute **attrs;
> +
> + struct attribute_group attr_group;
> + const struct attribute_group *groups[2];
> +};
> +
> +#define KELVIN_TO_MILLICELSIUS(x) (((x) - 273) * 1000)
> +
> +static int __cros_ec_hwmon_probe_fans(struct cros_ec_hwmon_priv *priv)
> +{
> + int err, idx;
> + uint16_t data;
> +
> + for (idx = 0; idx < EC_FAN_SPEED_ENTRIES; idx++) {
> + err = cros_ec_read_mapped_mem16(priv->ec,
> + EC_MEMMAP_FAN + 2 * idx,
> + &data);
Kind of interesting. ectool and ec code all assume that there is an
endianness match. Guess we can do the same. Just add a respective comment.
> + if (err)
> + return err;
> +
> + if (data == EC_FAN_SPEED_NOT_PRESENT)
> + break;
> + }
> +
> + return idx;
> +}
> +
> +static int __cros_ec_hwmon_probe_temps(struct cros_ec_hwmon_priv *priv)
> +{
> + uint8_t data;
> + int err, idx;
> +
> + err = cros_ec_read_mapped_mem8(priv->ec, EC_MEMMAP_THERMAL_VERSION,
> + &data);
> +
> + /* if we have a read error, or EC_MEMMAP_THERMAL_VERSION is not set,
> + * most likely we don't have temperature sensors ...
> + */
> + if (err || !data)
> + return 0;
> +
> + for (idx = 0; idx < EC_TEMP_SENSOR_ENTRIES; idx++) {
This doesn't cover EC_MEMMAP_THERMAL_VERSION >= 2 which supports
an additional set of thermal sensors.
> + err = cros_ec_read_mapped_mem8(priv->ec,
> + EC_MEMMAP_TEMP_SENSOR + idx,
> + &data);
You can read all data in one go using the provided callback function.
> + if (err)
> + return idx;
> +
> + /* this assumes that they're all good up to idx */
> + switch (data) {
> + case EC_TEMP_SENSOR_NOT_PRESENT:
> + case EC_TEMP_SENSOR_ERROR:
> + case EC_TEMP_SENSOR_NOT_POWERED:
> + case EC_TEMP_SENSOR_NOT_CALIBRATED:
Not sure if we can assume sensors to be in sequential order.
ectool doesn't make that assumption (it only does it for fans).
It might be safer to generate attributes for all possible sensors
and then use the is_visible function to determine which ones are
enabled.
> + return idx;
> + default:
> + continue;
> + };
> + }
> +
> + return idx;
> +}
> +
> +static ssize_t cros_ec_hwmon_read_fan_rpm(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + uint16_t data;
> + int err;
> + struct sensor_device_attribute *sattr = to_sensor_dev_attr(attr);
> + struct cros_ec_hwmon_priv *priv = dev_get_drvdata(dev);
> +
> + err = cros_ec_read_mapped_mem16(priv->ec,
> + EC_MEMMAP_FAN + 2 * sattr->index,
> + &data);
> + if (err)
> + return err;
> +
Watch out for EC_FAN_SPEED_STALLED.
> + return sprintf(buf, "%d\n", data);
> +}
> +
> +static ssize_t cros_ec_hwmon_read_temp(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + uint8_t data;
> + int err, tmp;
> +
> + struct sensor_device_attribute *sattr = to_sensor_dev_attr(attr);
> + struct cros_ec_hwmon_priv *priv = dev_get_drvdata(dev);
> +
> + err = cros_ec_read_mapped_mem8(priv->ec,
> + EC_MEMMAP_TEMP_SENSOR + 1 * sattr->index,
> + &data);
> + if (err)
> + return err;
> +
> + switch (data) {
> + case EC_TEMP_SENSOR_NOT_PRESENT:
> + case EC_TEMP_SENSOR_ERROR:
> + case EC_TEMP_SENSOR_NOT_POWERED:
> + case EC_TEMP_SENSOR_NOT_CALIBRATED:
> + dev_info(priv->ec->dev, "Failure: result=%d\n", data);
Please no logging noise.
> + return -EIO;
> + }
> +
> + /* make sure we don't overflow when adding offset*/
> + tmp = data + EC_TEMP_SENSOR_OFFSET;
> +
> + return sprintf(buf, "%d\n", KELVIN_TO_MILLICELSIUS(tmp));
Overall, a REG_TO_MILLICELSIUS() macro might be easier.
> +}
> +
> +static int cros_ec_hwmon_probe(struct platform_device *pdev)
> +{
> + struct cros_ec_device *ec = dev_get_drvdata(pdev->dev.parent);
> + struct cros_ec_hwmon_priv *ec_hwmon;
> + struct sensor_device_attribute *attr;
> + int num_fans, num_temps, i;
> +
> + ec_hwmon = devm_kzalloc(&pdev->dev, sizeof(*ec_hwmon), GFP_KERNEL);
> + if (!ec_hwmon)
> + return -ENOMEM;
> + ec_hwmon->ec = ec;
> +
> + num_fans = __cros_ec_hwmon_probe_fans(ec_hwmon);
> + if (num_fans < 0)
> + return num_fans;
> +
> + num_temps = __cros_ec_hwmon_probe_temps(ec_hwmon);
> + if (num_fans < 0)
> + return num_temps;
> +
> + ec_hwmon->attrs = devm_kzalloc(&pdev->dev,
> + sizeof(*ec_hwmon->attrs) *
> + (num_fans + num_temps + 1),
> + GFP_KERNEL);
> + if (!ec_hwmon->attrs)
> + return -ENOMEM;
> +
> + for (i = 0; i < num_fans; i++) {
> + attr = devm_kzalloc(&pdev->dev, sizeof(*attr), GFP_KERNEL);
> + if (!attr)
> + return -ENOMEM;
> + sysfs_attr_init(&attr->dev_attr.attr);
> + attr->dev_attr.attr.name = devm_kasprintf(&pdev->dev,
> + GFP_KERNEL,
> + "fan%d_input",
> + i);
> + if (!attr->dev_attr.attr.name)
> + return -ENOMEM;
> +
> + attr->dev_attr.show = cros_ec_hwmon_read_fan_rpm;
> + attr->dev_attr.attr.mode = S_IRUGO;
> + attr->index = i;
> + ec_hwmon->attrs[i] = &attr->dev_attr.attr;
> +
> + }
> +
> + for (i = 0; i < num_temps; i++) {
> + attr = devm_kzalloc(&pdev->dev, sizeof(*attr), GFP_KERNEL);
> + if (!attr)
> + return -ENOMEM;
> + sysfs_attr_init(&attr->dev_attr.attr);
> + attr->dev_attr.attr.name = devm_kasprintf(&pdev->dev,
> + GFP_KERNEL,
> + "temp%d_input",
> + i);
> + if (!attr->dev_attr.attr.name)
> + return -ENOMEM;
> +
> + attr->dev_attr.show = cros_ec_hwmon_read_temp;
> + attr->dev_attr.attr.mode = S_IRUGO;
> + attr->index = i;
> + ec_hwmon->attrs[i + num_fans] = &attr->dev_attr.attr;
> +
> + }
> +
> + ec_hwmon->attr_group.attrs = ec_hwmon->attrs;
> + ec_hwmon->groups[0] = &ec_hwmon->attr_group;
> +
> + ec_hwmon->hwmon_dev = devm_hwmon_device_register_with_groups(&pdev->dev,
> + "ec_hwmon", ec_hwmon, ec_hwmon->groups);
> +
hwmon_dev is only used in this function. There is no need to store it in
ec_hwmon.
> + if (IS_ERR(ec_hwmon->hwmon_dev))
> + return PTR_ERR(ec_hwmon->hwmon_dev);
> +
return PTR_ERR_OR_ZERO(hwmon_dev);
> + platform_set_drvdata(pdev, ec_hwmon);
> +
I don't see where this is used.
> + return 0;
> +}
> +
> +#ifdef CONFIG_OF
> +static const struct of_device_id cros_ec_hwmon_of_match[] = {
> + { .compatible = "google,cros-ec-hwmon" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, cros_ec_hwmon_of_match);
> +#endif
> +
> +static struct platform_driver cros_ec_hwmon_driver = {
> + .probe = cros_ec_hwmon_probe,
> + .driver = {
> + .name = "cros-ec-hwmon",
> + .of_match_table = of_match_ptr(cros_ec_hwmon_of_match),
> + },
> +};
> +module_platform_driver(cros_ec_hwmon_driver);
> +
> +MODULE_LICENSE("GPL v2");
> +MODULE_DESCRIPTION("ChromeOS EC Hardware Monitor driver");
> +MODULE_ALIAS("platform:cros-ec-hwmon");
> +MODULE_AUTHOR("Moritz Fischer <mdf@kernel.org>");
> --
> 2.7.4
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox