* [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
* Re: [PATCH v5] dt-bindings: fpga: Add bindings document for Xilinx LogiCore PR Decoupler
From: Rob Herring @ 2017-04-13 21:24 UTC (permalink / raw)
To: Alan Tull
Cc: Moritz Fischer, linux-fpga-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel,
Greg Kroah-Hartman, Michal Simek, Sören Brinkmann
In-Reply-To: <CANk1AXQGXdAY_vz5GzujQL1ziqa5W23bGvkUPU2u5BaJKhBzrA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Apr 13, 2017 at 3:25 PM, Alan Tull <atull-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Thu, Apr 13, 2017 at 3:07 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> On Sun, Apr 09, 2017 at 10:10:31AM -0700, Moritz Fischer wrote:
>>> This adds the binding documentation for the Xilinx LogiCORE PR
>>> Decoupler soft core.
>>>
>>> Signed-off-by: Moritz Fischer <mdf-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>> Signed-off-by: Michal Simek <michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
>>> Acked-by: Alan Tull <atull-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>> Cc: Sören Brinkmann <soren.brinkmann-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
>>> Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>> ---
>>>
>>> Changes from v4:
>>> - Ssubject line
>>> - Replaced 'or' by 'followed by' as suggested by Rob
>>>
>>> Changes from v3:
>>> - Addressed Michal's comments
>>> - Addressed Alan's Comments
>>> - Added Alan's Acked-by
>>>
>>> Changes from v2:
>>> - Added refence to generic fpga-region bindings
>>> - Fixed up reg property in example
>>> - Added fallback to "xlnx,pr-decoupler" without version
>>>
>>> Changes from v1:
>>> - Added clock names & clock to example
>>> - Merged some of the description from Michal's version
>>>
>>> ---
>>> .../bindings/fpga/xilinx-pr-decoupler.txt | 36 ++++++++++++++++++++++
>>> 1 file changed, 36 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
>>> new file mode 100644
>>> index 0000000..b2c58fb
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
>>> @@ -0,0 +1,36 @@
>>> +Xilinx LogiCORE Partial Reconfig Decoupler Softcore
>>> +
>>> +The Xilinx LogiCORE Partial Reconfig Decoupler manages one or more
>>> +decouplers / fpga bridges.
>>> +The controller can decouple/disable the bridges which prevents signal
>>> +changes from passing through the bridge. The controller can also
>>> +couple / enable the bridges which allows traffic to pass through the
>>> +bridge normally.
>>> +
>>> +The Driver supports only MMIO handling. A PR region can have multiple
>>> +PR Decouplers which can be handled independently or chained via decouple/
>>> +decouple_status signals.
>>> +
>>> +Required properties:
>>> +- compatible : Should contain "xlnx,pr-decoupler-1.00" followed by
>>> + "xlnx,pr-decoupler"
>>> +- regs : base address and size for decoupler module
>>> +- clocks : input clock to IP
>>> +- clock-names : should contain "aclk"
>>> +
>>> +Optional properties:
>>> +- bridge-enable : 0 if driver should disable bridge at startup
>>> + 1 if driver should enable bridge at startup
>>> + Default is to leave bridge in current state.
>>
>> Did this get into a common location? If so, then just "see .../?.txt" is
>> enough of a description.
>
> IIRC we went with this as is, with the intent of moving it to
> a common location in a separate patch. This binding shows
> up in a a few bindings docs, so one patch could move it from all
> of them at the same time. That hasn't happened yet.
Okay, I'll trust you to do that.
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@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
* [PATCH] ARM: dts: at91: use correct compatible for the gpio mux controller
From: Peter Rosin @ 2017-04-13 21:22 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Rosin, Nicolas Ferre, Alexandre Belloni, Rob Herring,
Mark Rutland, Russell King, linux-arm-kernel, devicetree
The compatible string for a gpio based mux controller is "gpio-mux",
and nothing else.
Fixes: 29dd89418007 ("ARM: dts: at91: add envelope detector mux to the Axentia TSE-850")
Signed-off-by: Peter Rosin <peda@axentia.se>
---
arch/arm/boot/dts/at91-tse850-3.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Hi!
The compatible string for the gpio based mux changed along the way (on
request from Rob) but I failed to update the implementation in the
gpio-mux driver when I made that change. Consequently, I didn't notice
that I didn't update the compatible string here either, since it all
continued to work in my tests...
The compatible string in the gpio-mux driver is being fixed to match
documentation, so this of course needs fixing too. No TSE-850 devices
are affected, except for the one on my desk.
Sorry for the churn.
Cheers,
peda
diff --git a/arch/arm/boot/dts/at91-tse850-3.dts b/arch/arm/boot/dts/at91-tse850-3.dts
index 6a724cfb5389..168665e56a56 100644
--- a/arch/arm/boot/dts/at91-tse850-3.dts
+++ b/arch/arm/boot/dts/at91-tse850-3.dts
@@ -204,7 +204,7 @@
};
mux: mux-controller {
- compatible = "mux-gpio";
+ compatible = "gpio-mux";
#mux-control-cells = <0>;
mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>,
--
2.1.4
^ permalink raw reply related
* Re: [PATCH 2/3] Documentation: dt: i2c: Add Altera I2C Controller
From: Rob Herring @ 2017-04-13 21:22 UTC (permalink / raw)
To: thor.thayer-VuQAYsv1563Yd54FQh9/CA
Cc: wsa-z923LK4zBo2bacvFa/9K2g, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1491926547-29510-3-git-send-email-thor.thayer-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On Tue, Apr 11, 2017 at 11:02:26AM -0500, thor.thayer-VuQAYsv1563Yd54FQh9/CA@public.gmane.org wrote:
> From: Thor Thayer <thor.thayer-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>
> Add the documentation to support the Altera I2C Controller.
"dt-bindings: i2c: ..." for the subject.
>
> Signed-off-by: Thor Thayer <thor.thayer-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> ---
> .../devicetree/bindings/i2c/i2c-altera.txt | 37 ++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-altera.txt
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-altera.txt b/Documentation/devicetree/bindings/i2c/i2c-altera.txt
> new file mode 100644
> index 0000000..a67241c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-altera.txt
> @@ -0,0 +1,37 @@
> +* Altera I2C Controller
This is the only one? For synthesizable logic or a hard block in
socfpga?
> +
> +Required properties :
> + - compatible : should be "altr,sip-i2c"
Seems kind of generic.
> + - reg : Offset and length of the register set for the device
> + - interrupts : <IRQ> where IRQ is the interrupt number.
> + - clocks : phandles to input clocks.
Need to specify how many clocks.
> + - #address-cells = <1>;
> + - #size-cells = <0>;
> +
> +Recommended properties :
> + - clock-frequency : desired I2C bus clock frequency in Hz.
> +
> +Optional properties :
> + - altr,fifo-size : Size of the RX and TX FIFOs.
in bytes?
Just "fifo-size" is already fairly common, so drop the vendor prefix.
> + - Child nodes conforming to i2c bus binding
> +
> +Example :
> +
> + i2c@100080000 {
> + compatible = "altr,sip-i2c";
> + reg = <0x00000001 0x00080000 0x00000040>;
> + interrupt-parent = <&intc>;
> + interrupts = <0 43 4>;
> + clocks = <&clk_0>;
> + clock-frequency = <100000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + altr,fifo-size = <4>;
> +
> + eeprom@51 {
> + compatible = "atmel,24c32";
> + reg = <0x51>;
> + pagesize = <32>;
> + };
> + };
> +
> --
> 1.9.1
>
--
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: Alexandre Belloni @ 2017-04-13 21:20 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Peter Rosin, linux-kernel, Wolfram Sang, devicetree, Russell King,
Rob Herring, Nicolas Ferre, Mark Rutland, linux-arm-kernel,
Geert Uytterhoeven
In-Reply-To: <dd93eb32-ca1e-5041-051e-c4f072f0f9a2@osg.samsung.com>
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@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
because we are past rc6).
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 4/8] ARM: dts: imx7s: Add node for GPC
From: Andrey Smirnov @ 2017-04-13 21:20 UTC (permalink / raw)
To: Fabio Estevam
Cc: Tyler Baker, 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,
Andrey Yurovsky
In-Reply-To: <CAOMZO5BjzSJws7zjJ5+aZkfeF+15twEu9zS3V+g6wQrtUiNyqQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Apr 13, 2017 at 1:49 PM, 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
>
FWIW, there's a patch for this that I haven't submitted yet (I plan to
submit it tomorrow):
https://github.com/ndreys/linux/commit/bd2de5be5c74bb35a0b8090f473862c9298a48b3
Thanks,
Andrey Smirnov
--
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: Andrey Smirnov @ 2017-04-13 21:19 UTC (permalink / raw)
To: Tyler Baker
Cc: Shawn Guo, Andrey Yurovsky, Sascha Hauer, Fabio Estevam,
Rob Herring, Mark Rutland, Russell King,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel
In-Reply-To: <CANMBJr5sFeVxVq2w2uUd-ehXi9SpaJ7W9S_PTS_VN25YZEdXvQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Apr 13, 2017 at 12:03 PM, Tyler Baker <tyler.baker-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> Hi Andrey,
>
> On 13 April 2017 at 06:32, Andrey Smirnov <andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> Add node for GPC and specify as a parent interrupt controller for SoC bus.
>>
>> Cc: yurovsky-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>> Cc: Sascha Hauer <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>> Cc: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
>> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
>> Cc: Russell King <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
>> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>> Signed-off-by: Andrey Smirnov <andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> ---
>> arch/arm/boot/dts/imx7s.dtsi | 27 ++++++++++++++++++++++++++-
>> 1 file changed, 26 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
>> index 8fee299..1a7058f 100644
>> --- a/arch/arm/boot/dts/imx7s.dtsi
>> +++ b/arch/arm/boot/dts/imx7s.dtsi
>> @@ -42,6 +42,7 @@
>> */
>>[0
>> #include <dt-bindings/clock/imx7d-clock.h>
>> +#include <dt-bindings/power/imx7-power.h>
>> #include <dt-bindings/gpio/gpio.h>
>> #include <dt-bindings/input/input.h>
>> #include <dt-bindings/interrupt-controller/arm-gic.h>
>> @@ -119,7 +120,7 @@
>> #address-cells = <1>;
>> #size-cells = <1>;
>> compatible = "simple-bus";
>> - interrupt-parent = <&intc>;
>> + interrupt-parent = <&gpc>;
>
> I've been testing your GPC/PCIe patch sets against v4.11-rc5 on my
> imx7d-cl-som-imx7, but hit a bit of a wall. When gpc is set as the
> interrupt-parent for the soc, the kernel seems to hang and not produce
> any output on the serial port[0]. I tried to enable earlyprintk, but
> no luck getting a trace. Reversing this change, gets the board
> booting[1], but obviously isn't using the gpc which is needed for PCIe
> support as I understand it. I assume you've tested these changes on a
> imx7d-sdb and are not seeing a similar issue? You can find the patches
> I've picked on top of v4.11-rc5 here[2], any idea what might be the
> issue?
Hmm, this is something new and I don't think I've seen it(neither that
nor the backtrace from your following e-mail). Here's the kernel tree
as I've been testing it:
https://github.com/ndreys/linux/commits/imx7d/pcie-support-v8
note, however, that it is based on d0ec4e6 (tip of pci/next when I was
rebasing) of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git,
which is not exactly v4.11-rc5
I'll rebase on top v4.11-r5 and see if I can get the same backtrace
you are getting and see if I can fix it.
Thanks and sorry for breaking things for you,
Andrey Smirnov
--
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
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