Re: [PATCH 0/3] rtc: remove intersil isl12057

[Arnaud Ebalard]

Hi Alexandre,

Alexandre Belloni <alexandre.bell...@free-electrons.com> writes:

> This is the series I intend to apply once you confirm my previous patch
> is working.

For previous patch and that series, once the typos are fixed:

Acked-by: Arnaud Ebalard <a...@natisbad.org>

Thanks for spotting the duplication and your work.

Cheers,

a+

>
> Alexandre Belloni (3):
>   Documentation: dt: Intersil isl12057 is not a trivial device
>   rtc: ds1307: add Intersil ISL12057 support
>   rtc: isl12057: remove driver
>
>  .../devicetree/bindings/i2c/trivial-devices.txt|   1 -
>  drivers/rtc/Kconfig|  18 +-
>  drivers/rtc/Makefile   |   1 -
>  drivers/rtc/rtc-ds1307.c   |   6 +
>  drivers/rtc/rtc-isl12057.c | 643 
> -
>  5 files changed, 10 insertions(+), 659 deletions(-)
>  delete mode 100644 drivers/rtc/rtc-isl12057.c

Re: [PATCH 0/3] rtc: remove intersil isl12057

[Arnaud Ebalard]

Hi Alexandre,

Alexandre Belloni  writes:

> This is the series I intend to apply once you confirm my previous patch
> is working.

For previous patch and that series, once the typos are fixed:

Acked-by: Arnaud Ebalard 

Thanks for spotting the duplication and your work.

Cheers,

a+

>
> Alexandre Belloni (3):
>   Documentation: dt: Intersil isl12057 is not a trivial device
>   rtc: ds1307: add Intersil ISL12057 support
>   rtc: isl12057: remove driver
>
>  .../devicetree/bindings/i2c/trivial-devices.txt|   1 -
>  drivers/rtc/Kconfig|  18 +-
>  drivers/rtc/Makefile   |   1 -
>  drivers/rtc/rtc-ds1307.c   |   6 +
>  drivers/rtc/rtc-isl12057.c | 643 
> -
>  5 files changed, 10 insertions(+), 659 deletions(-)
>  delete mode 100644 drivers/rtc/rtc-isl12057.c

Re: [PATCH 1/3] Documentation: dt: Intersil isl12057 is not a trivial device

[Arnaud Ebalard]

Hello,

Alexandre Belloni  writes:

> The ISL12057 has a documentation file, remove it from trivial-devices.txt
>
> Signed-off-by: Alexandre Belloni 
> ---
>  Documentation/devicetree/bindings/i2c/trivial-devices.txt | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt 
> b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> index 539874490492..a397d39ea741 100644
> --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> @@ -50,7 +50,6 @@ fsl,sgtl5000SGTL5000: Ultra Low-Power Audio 
> Codec
>  gmt,g751 G751: Digital Temperature Sensor and Thermal Watchdog 
> with Two-Wire Interface
>  infineon,slb9635tt   Infineon SLB9635 (Soft-) I2C TPM (old protocol, max 
> 100khz)
>  infineon,slb9645tt   Infineon SLB9645 I2C TPM (new protocol, max 400khz)
> -isil,isl12057Intersil ISL12057 I2C RTC Chip
>  isil,isl29028Intersil ISL29028 Ambient Light and Proximity 
> Sensor
>  maxim,ds1050 5 Bit Programmable, Pulse-Width Modulator
>  maxim,max1237Low-Power, 4-/12-Channel, 2-Wire Serial, 12-Bit 
> ADCs

No strong advice on this but I thought it qualified as a trivial device
because it did not *need* anything else except a compatible, an address
and possibly an interrupt. The additional boolean property documented in
Documentation/devicetree/bindings/rtc/isil,isl12057.txt is optional.

a+

Re: [PATCH 1/3] Documentation: dt: Intersil isl12057 is not a trivial device

[Arnaud Ebalard]

Hello,

Alexandre Belloni  writes:

> The ISL12057 has a documentation file, remove it from trivial-devices.txt
>
> Signed-off-by: Alexandre Belloni 
> ---
>  Documentation/devicetree/bindings/i2c/trivial-devices.txt | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt 
> b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> index 539874490492..a397d39ea741 100644
> --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> @@ -50,7 +50,6 @@ fsl,sgtl5000SGTL5000: Ultra Low-Power Audio 
> Codec
>  gmt,g751 G751: Digital Temperature Sensor and Thermal Watchdog 
> with Two-Wire Interface
>  infineon,slb9635tt   Infineon SLB9635 (Soft-) I2C TPM (old protocol, max 
> 100khz)
>  infineon,slb9645tt   Infineon SLB9645 I2C TPM (new protocol, max 400khz)
> -isil,isl12057Intersil ISL12057 I2C RTC Chip
>  isil,isl29028Intersil ISL29028 Ambient Light and Proximity 
> Sensor
>  maxim,ds1050 5 Bit Programmable, Pulse-Width Modulator
>  maxim,max1237Low-Power, 4-/12-Channel, 2-Wire Serial, 12-Bit 
> ADCs

No strong advice on this but I thought it qualified as a trivial device
because it did not *need* anything else except a compatible, an address
and possibly an interrupt. The additional boolean property documented in
Documentation/devicetree/bindings/rtc/isil,isl12057.txt is optional.

a+

Re: [PATCH] rtc: ds1307: fix century bit support

[Arnaud Ebalard]

Hi Alexandre,

Alexandre Belloni  writes:

> Add an option to properly support the century bit of ds1337 and compatibles
> and ds1340.
> Because the driver had a bug until now, it is not possible to switch users
> to the fixed code directly as RTCs in the field will wrongly have the
> century bit set.
>
> Signed-off-by: Alexandre Belloni 
> ---
>
> Arnaud, do you mind testing that patch, I still don't have the necessary
> hardware but I think this is the proper course of action.

I did some tests w/ all patches applied (the one below and the ones in
the other series). I had to fix two errors: one pointed in the patch
below and the other one in a patch in the other series (I'll reply to
the patch).

With both RTC_DRV_DS1307 and RTC_DRV_DS1307_CENTURY enabled, this works
as expected on my side: booting on a system which had only seen an
ISL12057 driver, the time on the system at boot (or via hwclock -r) is
correct. Playing w/ -s and -w options works as expected. Booting back on
a kernel w/ ISL12057 driver, things are also ok. So, AFAICT, your
changes do the work.

One small thing though: for user which have always used RTC_DRV_ISL12057
config knob, the change will not be transparent. Would it be possible to
somehow make that old kernel config knob some kind of alias for
RTC_DRV_DS1307 and RTC_DRV_DS1307_CENTURY in Kconfig?

Cheers,

a+


> +#ifdef CONFIG_RTC_DRV_DS1307_CENTURY
> + switch (ds1307->type) {
> + case ds_1337:
> + case ds_1339:
> + case ds_3231:
> + if (ds1307->regs[DS1307_REG_MONTH] && DS1337_BIT_CENTURY)

   ^^


> + t->tm_year += 100;
> + break;
> + case ds_1340:
> + if (ds1307->regs[DS1307_REG_HOUR] && DS1340_BIT_CENTURY)

  ^^

Re: [PATCH 2/3] rtc: ds1307: add Intersil ISL12057 support

[Arnaud Ebalard]

Alexandre Belloni  writes:

> Intersil ISL12057 is a drop-in replacement for DS1337. It can be supported
> by the ds1307 driver.
>
> Signed-off-by: Alexandre Belloni 
> ---
>  drivers/rtc/Kconfig  | 8 
>  drivers/rtc/rtc-ds1307.c | 6 ++
>  2 files changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index f47c2f5ff70d..ba0b3e7ce4c5 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -198,14 +198,14 @@ config RTC_DRV_AS3722
> will be called rtc-as3722.
>  
>  config RTC_DRV_DS1307
> - tristate "Dallas/Maxim DS1307/37/38/39/40, ST M41T00, EPSON RX-8025"
> + tristate "Dallas/Maxim DS1307/37/38/39/40, ST M41T00, EPSON RX-8025, 
> ISL12057"
>   help
> If you say yes here you get support for various compatible RTC
> chips (often with battery backup) connected with I2C. This driver
> should handle DS1307, DS1337, DS1338, DS1339, DS1340, ST M41T00,
> -   EPSON RX-8025 and probably other chips. In some cases the RTC
> -   must already have been initialized (by manufacturing or a
> -   bootloader).
> +   EPSON RX-8025, Intersil ISL12057 and probably other chips. In some
> +   cases the RTC must already have been initialized (by manufacturing or
> +   a bootloader).
>  
> The first seven registers on these chips hold an RTC, and other
> registers may add features such as NVRAM, a trickle charger for
> diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
> index 4c5890864d9c..52be48f2e3c0 100644
> --- a/drivers/rtc/rtc-ds1307.c
> +++ b/drivers/rtc/rtc-ds1307.c
> @@ -186,6 +186,7 @@ static const struct i2c_device_id ds1307_id[] = {
>   { "mcp7941x", mcp794xx },
>   { "pt7c4338", ds_1307 },
>   { "rx8025", rx_8025 },
> + { "isl1207", ds_1337 },

  "isl12057"

Re: [PATCH] rtc: ds1307: fix century bit support

[Arnaud Ebalard]

Hi Alexandre,

Alexandre Belloni  writes:

> Add an option to properly support the century bit of ds1337 and compatibles
> and ds1340.
> Because the driver had a bug until now, it is not possible to switch users
> to the fixed code directly as RTCs in the field will wrongly have the
> century bit set.
>
> Signed-off-by: Alexandre Belloni 
> ---
>
> Arnaud, do you mind testing that patch, I still don't have the necessary
> hardware but I think this is the proper course of action.

I did some tests w/ all patches applied (the one below and the ones in
the other series). I had to fix two errors: one pointed in the patch
below and the other one in a patch in the other series (I'll reply to
the patch).

With both RTC_DRV_DS1307 and RTC_DRV_DS1307_CENTURY enabled, this works
as expected on my side: booting on a system which had only seen an
ISL12057 driver, the time on the system at boot (or via hwclock -r) is
correct. Playing w/ -s and -w options works as expected. Booting back on
a kernel w/ ISL12057 driver, things are also ok. So, AFAICT, your
changes do the work.

One small thing though: for user which have always used RTC_DRV_ISL12057
config knob, the change will not be transparent. Would it be possible to
somehow make that old kernel config knob some kind of alias for
RTC_DRV_DS1307 and RTC_DRV_DS1307_CENTURY in Kconfig?

Cheers,

a+


> +#ifdef CONFIG_RTC_DRV_DS1307_CENTURY
> + switch (ds1307->type) {
> + case ds_1337:
> + case ds_1339:
> + case ds_3231:
> + if (ds1307->regs[DS1307_REG_MONTH] && DS1337_BIT_CENTURY)

   ^^


> + t->tm_year += 100;
> + break;
> + case ds_1340:
> + if (ds1307->regs[DS1307_REG_HOUR] && DS1340_BIT_CENTURY)

  ^^

Re: [PATCH 2/3] rtc: ds1307: add Intersil ISL12057 support

[Arnaud Ebalard]

Alexandre Belloni  writes:

> Intersil ISL12057 is a drop-in replacement for DS1337. It can be supported
> by the ds1307 driver.
>
> Signed-off-by: Alexandre Belloni 
> ---
>  drivers/rtc/Kconfig  | 8 
>  drivers/rtc/rtc-ds1307.c | 6 ++
>  2 files changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index f47c2f5ff70d..ba0b3e7ce4c5 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -198,14 +198,14 @@ config RTC_DRV_AS3722
> will be called rtc-as3722.
>  
>  config RTC_DRV_DS1307
> - tristate "Dallas/Maxim DS1307/37/38/39/40, ST M41T00, EPSON RX-8025"
> + tristate "Dallas/Maxim DS1307/37/38/39/40, ST M41T00, EPSON RX-8025, 
> ISL12057"
>   help
> If you say yes here you get support for various compatible RTC
> chips (often with battery backup) connected with I2C. This driver
> should handle DS1307, DS1337, DS1338, DS1339, DS1340, ST M41T00,
> -   EPSON RX-8025 and probably other chips. In some cases the RTC
> -   must already have been initialized (by manufacturing or a
> -   bootloader).
> +   EPSON RX-8025, Intersil ISL12057 and probably other chips. In some
> +   cases the RTC must already have been initialized (by manufacturing or
> +   a bootloader).
>  
> The first seven registers on these chips hold an RTC, and other
> registers may add features such as NVRAM, a trickle charger for
> diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
> index 4c5890864d9c..52be48f2e3c0 100644
> --- a/drivers/rtc/rtc-ds1307.c
> +++ b/drivers/rtc/rtc-ds1307.c
> @@ -186,6 +186,7 @@ static const struct i2c_device_id ds1307_id[] = {
>   { "mcp7941x", mcp794xx },
>   { "pt7c4338", ds_1307 },
>   { "rx8025", rx_8025 },
> + { "isl1207", ds_1337 },

  "isl12057"

[PATCH 2/2] arm: mvebu: reorder nodes under internal-regs by address in RN2120 .dts file

[Arnaud Ebalard]

This cosmetic patch reorder nodes under internal-regs by increasing
address order, as epxected.

Signed-off-by: Arnaud Ebalard 
---
 arch/arm/boot/dts/armada-xp-netgear-rn2120.dts | 86 +-
 1 file changed, 43 insertions(+), 43 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts 
b/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts
index 85b2f87c0b8a..d72a69d97ba2 100644
--- a/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts
+++ b/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts
@@ -94,54 +94,11 @@
status = "disabled";
};
 
-   /* Two rear eSATA ports */
-   sata@a {
-   nr-ports = <2>;
-   status = "okay";
-   };
-
-   serial@12000 {
-   status = "okay";
-   };
-
-   mdio {
-   phy0: ethernet-phy@0 { /* Marvell 88E1318 */
-   reg = <0>;
-   };
-
-   phy1: ethernet-phy@1 { /* Marvell 88E1318 */
-   reg = <1>;
-   };
-   };
-
-   ethernet@7 {
-   status = "okay";
-   phy = <>;
-   phy-mode = "rgmii-id";
-   };
-
-   ethernet@74000 {
-   status = "okay";
-   phy = <>;
-   phy-mode = "rgmii-id";
-   };
-
-   /* Front USB 2.0 port */
-   usb@5 {
-   status = "okay";
-   };
-
i2c@11000 {
compatible = "marvell,mv64xxx-i2c";
clock-frequency = <40>;
status = "okay";
 
-   isl12057: isl12057@68 {
-   compatible = "isil,isl12057";
-   reg = <0x68>;
-   isil,irq2-can-wakeup-machine;
-   };
-
/* Controller for rear fan #1 of 3 (Protechnic
 * MGT4012XB-O20, 8000RPM) near eSATA port */
g762_fan1: g762@3e {
@@ -178,6 +135,49 @@
compatible = "gmt,g751";
reg = <0x4c>;
};
+
+   isl12057: isl12057@68 {
+   compatible = "isil,isl12057";
+   reg = <0x68>;
+   isil,irq2-can-wakeup-machine;
+   };
+   };
+
+   serial@12000 {
+   status = "okay";
+   };
+
+   /* Front USB 2.0 port */
+   usb@5 {
+   status = "okay";
+   };
+
+   mdio {
+   phy0: ethernet-phy@0 { /* Marvell 88E1318 */
+   reg = <0>;
+   };
+
+   phy1: ethernet-phy@1 { /* Marvell 88E1318 */
+   reg = <1>;
+   };
+   };
+
+   ethernet@7 {
+   status = "okay";
+   phy = <>;
+   phy-mode = "rgmii-id";
+   };
+
+   ethernet@74000 {
+   status = "okay";
+   phy = <>;
+   phy-mode = "rgmii-id";
+   };
+
+   /* Two rear eSATA ports */
+   sata@a {
+   nr-ports = <2>;
+   status = "okay";
};
 
nand@d {
-- 
2.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] arm: mvebu: disable unused Armada RTC on ReadyNAS 102, 104 and 2120

[Arnaud Ebalard]

By default, armada-370-xp.dtsi file has internal RTC enabled.
NETGEAR ReadyNAS 102, 104 and 2120 all use an Intersil ISL12057
I2C RTC chip. The internal RTC not being disabled in the .dts
files of those devices result in the following useless first
line during boot:

[4.500056] rtc-mv d0010300.rtc: internal RTC not ticking
[4.505684] i2c /dev entries driver
[4.513246] rtc-isl12057 0-0068: rtc core: registered rtc-isl12057 as rtc0

This patch marks Armada internal RTC as disabled in individual .dts
files of those devices.

Reported-by: TuxOholic 
Signed-off-by: Arnaud Ebalard 
---
 arch/arm/boot/dts/armada-370-netgear-rn102.dts | 6 ++
 arch/arm/boot/dts/armada-370-netgear-rn104.dts | 6 ++
 arch/arm/boot/dts/armada-xp-netgear-rn2120.dts | 6 ++
 3 files changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/armada-370-netgear-rn102.dts 
b/arch/arm/boot/dts/armada-370-netgear-rn102.dts
index a31207860f34..5851964196bd 100644
--- a/arch/arm/boot/dts/armada-370-netgear-rn102.dts
+++ b/arch/arm/boot/dts/armada-370-netgear-rn102.dts
@@ -82,6 +82,12 @@
};
 
internal-regs {
+
+   /* RTC is provided by Intersil ISL12057 I2C RTC chip */
+   rtc@10300 {
+   status = "disabled";
+   };
+
serial@12000 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/armada-370-netgear-rn104.dts 
b/arch/arm/boot/dts/armada-370-netgear-rn104.dts
index 00540f292979..b0b07ba677b9 100644
--- a/arch/arm/boot/dts/armada-370-netgear-rn104.dts
+++ b/arch/arm/boot/dts/armada-370-netgear-rn104.dts
@@ -82,6 +82,12 @@
};
 
internal-regs {
+
+   /* RTC is provided by Intersil ISL12057 I2C RTC chip */
+   rtc@10300 {
+   status = "disabled";
+   };
+
serial@12000 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts 
b/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts
index 1516fc2627f9..85b2f87c0b8a 100644
--- a/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts
+++ b/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts
@@ -88,6 +88,12 @@
};
 
internal-regs {
+
+   /* RTC is provided by Intersil ISL12057 I2C RTC chip */
+   rtc@10300 {
+   status = "disabled";
+   };
+
/* Two rear eSATA ports */
sata@a {
nr-ports = <2>;
-- 
2.5.3


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/2] arm: mvebu: disable unused rtc + cosmetic patch for ReadyNAS devices

[Arnaud Ebalard]

Hi,

Here are two simple patches for Armada-based ReadyNAS devices.

The first one disables Armada 370/XP rtc in the .dts files of ReadyNAS
102, 104 and 2120 devices. Those use an Intersil ISL12057 I2C RTC chip
and do not use the internal Armada RTC. Because it is enabled in
included armada-370-xp.dtsi, it just pollutes logs during boot.

While writing the patches, I noticed RN2120 .dts file has nodes that
are badly ordered under internal-regs. This second patch fixes
that. Note that it depends on first patch. 

Arnaud Ebalard (2):
  arm: mvebu: disable unused Armada RTC on ReadyNAS 102, 104 and 2120
  arm: mvebu: reorder internal-regs nodes by address in RN2120 .dts file

 arch/arm/boot/dts/armada-370-netgear-rn102.dts |  6 ++
 arch/arm/boot/dts/armada-370-netgear-rn104.dts |  6 ++
 arch/arm/boot/dts/armada-xp-netgear-rn2120.dts | 86 ++
 3 files changed, 58 insertions(+), 40 deletions(-)

-- 
2.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/2] arm: mvebu: disable unused rtc + cosmetic patch for ReadyNAS devices

[Arnaud Ebalard]

Hi,

Here are two simple patches for Armada-based ReadyNAS devices.

The first one disables Armada 370/XP rtc in the .dts files of ReadyNAS
102, 104 and 2120 devices. Those use an Intersil ISL12057 I2C RTC chip
and do not use the internal Armada RTC. Because it is enabled in
included armada-370-xp.dtsi, it just pollutes logs during boot.

While writing the patches, I noticed RN2120 .dts file has nodes that
are badly ordered under internal-regs. This second patch fixes
that. Note that it depends on first patch. 

Arnaud Ebalard (2):
  arm: mvebu: disable unused Armada RTC on ReadyNAS 102, 104 and 2120
  arm: mvebu: reorder internal-regs nodes by address in RN2120 .dts file

 arch/arm/boot/dts/armada-370-netgear-rn102.dts |  6 ++
 arch/arm/boot/dts/armada-370-netgear-rn104.dts |  6 ++
 arch/arm/boot/dts/armada-xp-netgear-rn2120.dts | 86 ++
 3 files changed, 58 insertions(+), 40 deletions(-)

-- 
2.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] arm: mvebu: disable unused Armada RTC on ReadyNAS 102, 104 and 2120

[Arnaud Ebalard]

By default, armada-370-xp.dtsi file has internal RTC enabled.
NETGEAR ReadyNAS 102, 104 and 2120 all use an Intersil ISL12057
I2C RTC chip. The internal RTC not being disabled in the .dts
files of those devices result in the following useless first
line during boot:

[4.500056] rtc-mv d0010300.rtc: internal RTC not ticking
[4.505684] i2c /dev entries driver
[4.513246] rtc-isl12057 0-0068: rtc core: registered rtc-isl12057 as rtc0

This patch marks Armada internal RTC as disabled in individual .dts
files of those devices.

Reported-by: TuxOholic <tuxoho...@hotmail.de>
Signed-off-by: Arnaud Ebalard <a...@natisbad.org>
---
 arch/arm/boot/dts/armada-370-netgear-rn102.dts | 6 ++
 arch/arm/boot/dts/armada-370-netgear-rn104.dts | 6 ++
 arch/arm/boot/dts/armada-xp-netgear-rn2120.dts | 6 ++
 3 files changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/armada-370-netgear-rn102.dts 
b/arch/arm/boot/dts/armada-370-netgear-rn102.dts
index a31207860f34..5851964196bd 100644
--- a/arch/arm/boot/dts/armada-370-netgear-rn102.dts
+++ b/arch/arm/boot/dts/armada-370-netgear-rn102.dts
@@ -82,6 +82,12 @@
};
 
internal-regs {
+
+   /* RTC is provided by Intersil ISL12057 I2C RTC chip */
+   rtc@10300 {
+   status = "disabled";
+   };
+
serial@12000 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/armada-370-netgear-rn104.dts 
b/arch/arm/boot/dts/armada-370-netgear-rn104.dts
index 00540f292979..b0b07ba677b9 100644
--- a/arch/arm/boot/dts/armada-370-netgear-rn104.dts
+++ b/arch/arm/boot/dts/armada-370-netgear-rn104.dts
@@ -82,6 +82,12 @@
};
 
internal-regs {
+
+   /* RTC is provided by Intersil ISL12057 I2C RTC chip */
+   rtc@10300 {
+   status = "disabled";
+   };
+
serial@12000 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts 
b/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts
index 1516fc2627f9..85b2f87c0b8a 100644
--- a/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts
+++ b/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts
@@ -88,6 +88,12 @@
};
 
internal-regs {
+
+   /* RTC is provided by Intersil ISL12057 I2C RTC chip */
+   rtc@10300 {
+   status = "disabled";
+   };
+
/* Two rear eSATA ports */
sata@a {
nr-ports = <2>;
-- 
2.5.3


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] arm: mvebu: reorder nodes under internal-regs by address in RN2120 .dts file

[Arnaud Ebalard]

This cosmetic patch reorder nodes under internal-regs by increasing
address order, as epxected.

Signed-off-by: Arnaud Ebalard <a...@natisbad.org>
---
 arch/arm/boot/dts/armada-xp-netgear-rn2120.dts | 86 +-
 1 file changed, 43 insertions(+), 43 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts 
b/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts
index 85b2f87c0b8a..d72a69d97ba2 100644
--- a/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts
+++ b/arch/arm/boot/dts/armada-xp-netgear-rn2120.dts
@@ -94,54 +94,11 @@
status = "disabled";
};
 
-   /* Two rear eSATA ports */
-   sata@a {
-   nr-ports = <2>;
-   status = "okay";
-   };
-
-   serial@12000 {
-   status = "okay";
-   };
-
-   mdio {
-   phy0: ethernet-phy@0 { /* Marvell 88E1318 */
-   reg = <0>;
-   };
-
-   phy1: ethernet-phy@1 { /* Marvell 88E1318 */
-   reg = <1>;
-   };
-   };
-
-   ethernet@7 {
-   status = "okay";
-   phy = <>;
-   phy-mode = "rgmii-id";
-   };
-
-   ethernet@74000 {
-   status = "okay";
-   phy = <>;
-   phy-mode = "rgmii-id";
-   };
-
-   /* Front USB 2.0 port */
-   usb@5 {
-   status = "okay";
-   };
-
i2c@11000 {
compatible = "marvell,mv64xxx-i2c";
clock-frequency = <40>;
status = "okay";
 
-   isl12057: isl12057@68 {
-   compatible = "isil,isl12057";
-   reg = <0x68>;
-   isil,irq2-can-wakeup-machine;
-   };
-
/* Controller for rear fan #1 of 3 (Protechnic
 * MGT4012XB-O20, 8000RPM) near eSATA port */
g762_fan1: g762@3e {
@@ -178,6 +135,49 @@
compatible = "gmt,g751";
reg = <0x4c>;
};
+
+   isl12057: isl12057@68 {
+   compatible = "isil,isl12057";
+   reg = <0x68>;
+   isil,irq2-can-wakeup-machine;
+   };
+   };
+
+   serial@12000 {
+   status = "okay";
+   };
+
+   /* Front USB 2.0 port */
+   usb@5 {
+   status = "okay";
+   };
+
+   mdio {
+   phy0: ethernet-phy@0 { /* Marvell 88E1318 */
+   reg = <0>;
+   };
+
+   phy1: ethernet-phy@1 { /* Marvell 88E1318 */
+   reg = <1>;
+   };
+   };
+
+   ethernet@7 {
+   status = "okay";
+   phy = <>;
+   phy-mode = "rgmii-id";
+   };
+
+   ethernet@74000 {
+   status = "okay";
+   phy = <>;
+   phy-mode = "rgmii-id";
+   };
+
+   /* Two rear eSATA ports */
+   sata@a {
+   nr-ports = <2>;
+   status = "okay";
};
 
nand@d {
-- 
2.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net v5 0/4] net: enable inband link state negotiation only when explicitly requested

[Arnaud Ebalard]

Hi guys,

Florian Fainelli  writes:

> Changes in v5:
>
> - removed an invalid use of the link_update callback in the SF2 driver
>   was appeared after merging "net: phy: fixed_phy: handle link-down case"
>
> - reworded the commit message for patch 2 to make it clear what it fixes and
>   why this is required
>
> Initial cover letter from Stas:
>
> Hello.
>
> Currently the link status auto-negotiation is enabled
> for any SGMII link with fixed-link DT binding.
> The regression was reported:
> https://lkml.org/lkml/2015/7/8/865
> Apparently not all HW that implements SGMII protocol, generates the
> inband status for the auto-negotiation to work.
> More details here:
> https://lkml.org/lkml/2015/7/10/206
>
> The following patches reverts to the old behavior by default,
> which is to not enable the auto-negotiation for fixed-link.
> The new DT property is added that allows to explicitly request
> the auto-negotiation.

FWIW, I tested this v5 series on mirabox (2 mvneta interfaces using
RGMII); both interfaces still work as expected, i.e. no regression
on my side.

a+
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net v5 0/4] net: enable inband link state negotiation only when explicitly requested

[Arnaud Ebalard]

Hi guys,

Florian Fainelli f.faine...@gmail.com writes:

 Changes in v5:

 - removed an invalid use of the link_update callback in the SF2 driver
   was appeared after merging net: phy: fixed_phy: handle link-down case

 - reworded the commit message for patch 2 to make it clear what it fixes and
   why this is required

 Initial cover letter from Stas:

 Hello.

 Currently the link status auto-negotiation is enabled
 for any SGMII link with fixed-link DT binding.
 The regression was reported:
 https://lkml.org/lkml/2015/7/8/865
 Apparently not all HW that implements SGMII protocol, generates the
 inband status for the auto-negotiation to work.
 More details here:
 https://lkml.org/lkml/2015/7/10/206

 The following patches reverts to the old behavior by default,
 which is to not enable the auto-negotiation for fixed-link.
 The new DT property is added that allows to explicitly request
 the auto-negotiation.

FWIW, I tested this v5 series on mirabox (2 mvneta interfaces using
RGMII); both interfaces still work as expected, i.e. no regression
on my side.

a+
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4.1 11/56] mvneta: add forgotten initialization of autonegotiation bits

[Arnaud Ebalard]

Hi,

Stas Sergeev  writes:

>>> Another problem was reported:
>>> https://lkml.org/lkml/2015/7/8/865
>>>
>>> So, while the above patch is correct and fixes what
>>> it should, the original patch has more problems to deal
>>> with. Maybe for stable it would be better to just revert
>>> the whole thing?
>> No, you will have to fix this in Linus's tree, right?  So I'll take the
>> patch that you get into there when that happens, I don't want to diverge
>> from what is in that tree.
> For Linus tree I am planning a new DT property to explicitly
> enable the inband status. I don't see any quick fix suitable for
> -stable, and new DT property will likely not be quickly accepted.
> If you don't want a revert, then the stable will likely have that
> regression for quite long, that's the warning.

I do not think the problem is to have a revert in -stable, it's more
having in in Linus tree *first* ;-)

> OTOH, the revert will remove the support for my board, so I
> won't be able to even test it, which is also not perfect.

ATM, the priority is more on fixing the regressions the initial patch
caused *for existing boards*. There were at least three boards which got
hit by first regression during 4.1-rc and a new one on the table now
that 4.1 is out. I understand your reluctance to revert the patch that
made mvneta work for your custom board but it's unfair for others that
are hit by the regressions it causes and have to spend time
bisecting/fixing it.

Anyway, if you come w/ a fix, I can commit to test it on the boards I
have.

Cheers,

a+
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4.1 11/56] mvneta: add forgotten initialization of autonegotiation bits

[Arnaud Ebalard]

Hi,

Stas Sergeev s...@list.ru writes:

 Another problem was reported:
 https://lkml.org/lkml/2015/7/8/865

 So, while the above patch is correct and fixes what
 it should, the original patch has more problems to deal
 with. Maybe for stable it would be better to just revert
 the whole thing?
 No, you will have to fix this in Linus's tree, right?  So I'll take the
 patch that you get into there when that happens, I don't want to diverge
 from what is in that tree.
 For Linus tree I am planning a new DT property to explicitly
 enable the inband status. I don't see any quick fix suitable for
 -stable, and new DT property will likely not be quickly accepted.
 If you don't want a revert, then the stable will likely have that
 regression for quite long, that's the warning.

I do not think the problem is to have a revert in -stable, it's more
having in in Linus tree *first* ;-)

 OTOH, the revert will remove the support for my board, so I
 won't be able to even test it, which is also not perfect.

ATM, the priority is more on fixing the regressions the initial patch
caused *for existing boards*. There were at least three boards which got
hit by first regression during 4.1-rc and a new one on the table now
that 4.1 is out. I understand your reluctance to revert the patch that
made mvneta work for your custom board but it's unfair for others that
are hit by the regressions it causes and have to spend time
bisecting/fixing it.

Anyway, if you come w/ a fix, I can commit to test it on the boards I
have.

Cheers,

a+
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] crypto: add new driver for Marvell CESA

[Arnaud Ebalard]

Hi Jason,

Jason Cooper  writes:

> It's not about the crypto, it's about trust.  imho, one of the most
> important security advances in the past 20 years is the default use of
> git (or other SCMs) by open source projects.  Now, no one is forced to
> trust the authors and maintainers tarball dumps.  Regular code audits
> and security updates are *much* more feasible because you can audit
> small changes.  It can even be automated to a large extent.
>
> All this means the user has a choice: they can trust the authors and
> maintainers, or they can trust their own audits.  Since updates are an
> essential part of a security posture, small commits facilitate
> maintaining the 'trust in audits'.
>
> It's not about "Should you trust free-electrons?"  Or, "Should you trust
> Jason / Herbert / Linus?"  It's about "Should you have to trust any of
> them?"

It's ok, you can call our driver fat. It is ;-) More seriously, I tend
to agree w/ what you write above.


>> >> I really tried to adapt the existing driver to add the missing
>> >> features (especially the support for TDMA), but all my attempts
>> >> ended up introducing hackish code (not even talking about the
>> >> performance penalty of this approach).
>> > 
>> > Ok, fair enough.  It would be helpful if this account of attempting to
>> > reconcile the old driver made it into the commit message.  This puts us
>> > in "perfect is the enemy of getting it done" territory.
>> > 
>> >> I have another solution though: keep the existing driver for old
>> >> marvell SoCs (orion, kirkwood and dove), and add a new one for modern
>> >> SoCs (armada 370, XP, 375 and 38x), so that users of the mv_cesa driver
>> >> won't have to audit the new code.
>> > 
>> > A fair proposal, but I'll freely admit the number of people actually 
>> > auditing
>> > their code paths is orders of magnitude smaller than the number of users
>> > of the driver.
>> > 
>> > There's such a large population of compatible legacy SoCs in the wild,
>> > adding an artificial boundary doesn't make sense.  Especially since
>> > we're talking about features everyone would want to use.
>> > 
>> > Perhaps we should keep both around, and deprecate the legacy driver over
>> > 3 to 4 cycles?
>> 
>> But I guess that some users will want to use the new driver on the "old" 
>> marvell
>> SoCs (especially kirkwood and dove).
>
> Yes, despite my arguments, I'm one of those people.  :-P
>
>> If we go to this path, then the best solution would be to still update
>> all the the dts, and modifying the old driver to be able to use the
>> new binding: for my point of view the only adaptation should be
>> related to the SRAM. It will be also needed to find a way to be able
>> to load only one driver at a time: either the old or the new, but not
>> both.

The approach Boris proposed above seems to make everyone happy:

 1) Keep the old driver for old marvells SoCs (kirkwood, dove and orion)
 2) Introduce the new driver for those that are not supported by the old
driver, i.e. armada (370, XP, 375, 38x)

AFAICT, this can easily be done (based on compatible strings) and it
will let everyone the time to audit the new driver. Current users will
not be taken by surprise. At some point, when everyone is confident w/
the new driver, we can then switch to that one for all SoCs so that
old platform get more performance.

Additionnally, for those who want to get the feature of the new driver
for their old SoC right now, we *could* add a simple kernel config option
for the new driver to use it for the old SoC too (that one disabling the
old one).


> I'd appreciate if we'd look into it.  I understand from on-list and
> off-list discussion that the rewrite was unavoidable.  So I'm willing to
> concede that.  Giving people time to migrate from old to new while still
> being able to update for other security fixes seems reasonable.

Jason, what do you think of the approach above? 

Cheers,

a+
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] crypto: add new driver for Marvell CESA

[Arnaud Ebalard]

Hi Jason,

Jason Cooper ja...@lakedaemon.net writes:

 It's not about the crypto, it's about trust.  imho, one of the most
 important security advances in the past 20 years is the default use of
 git (or other SCMs) by open source projects.  Now, no one is forced to
 trust the authors and maintainers tarball dumps.  Regular code audits
 and security updates are *much* more feasible because you can audit
 small changes.  It can even be automated to a large extent.

 All this means the user has a choice: they can trust the authors and
 maintainers, or they can trust their own audits.  Since updates are an
 essential part of a security posture, small commits facilitate
 maintaining the 'trust in audits'.

 It's not about Should you trust free-electrons?  Or, Should you trust
 Jason / Herbert / Linus?  It's about Should you have to trust any of
 them?

It's ok, you can call our driver fat. It is ;-) More seriously, I tend
to agree w/ what you write above.


  I really tried to adapt the existing driver to add the missing
  features (especially the support for TDMA), but all my attempts
  ended up introducing hackish code (not even talking about the
  performance penalty of this approach).
  
  Ok, fair enough.  It would be helpful if this account of attempting to
  reconcile the old driver made it into the commit message.  This puts us
  in perfect is the enemy of getting it done territory.
  
  I have another solution though: keep the existing driver for old
  marvell SoCs (orion, kirkwood and dove), and add a new one for modern
  SoCs (armada 370, XP, 375 and 38x), so that users of the mv_cesa driver
  won't have to audit the new code.
  
  A fair proposal, but I'll freely admit the number of people actually 
  auditing
  their code paths is orders of magnitude smaller than the number of users
  of the driver.
  
  There's such a large population of compatible legacy SoCs in the wild,
  adding an artificial boundary doesn't make sense.  Especially since
  we're talking about features everyone would want to use.
  
  Perhaps we should keep both around, and deprecate the legacy driver over
  3 to 4 cycles?
 
 But I guess that some users will want to use the new driver on the old 
 marvell
 SoCs (especially kirkwood and dove).

 Yes, despite my arguments, I'm one of those people.  :-P

 If we go to this path, then the best solution would be to still update
 all the the dts, and modifying the old driver to be able to use the
 new binding: for my point of view the only adaptation should be
 related to the SRAM. It will be also needed to find a way to be able
 to load only one driver at a time: either the old or the new, but not
 both.

The approach Boris proposed above seems to make everyone happy:

 1) Keep the old driver for old marvells SoCs (kirkwood, dove and orion)
 2) Introduce the new driver for those that are not supported by the old
driver, i.e. armada (370, XP, 375, 38x)

AFAICT, this can easily be done (based on compatible strings) and it
will let everyone the time to audit the new driver. Current users will
not be taken by surprise. At some point, when everyone is confident w/
the new driver, we can then switch to that one for all SoCs so that
old platform get more performance.

Additionnally, for those who want to get the feature of the new driver
for their old SoC right now, we *could* add a simple kernel config option
for the new driver to use it for the old SoC too (that one disabling the
old one).


 I'd appreciate if we'd look into it.  I understand from on-list and
 off-list discussion that the rewrite was unavoidable.  So I'm willing to
 concede that.  Giving people time to migrate from old to new while still
 being able to update for other security fixes seems reasonable.

Jason, what do you think of the approach above? 

Cheers,

a+
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: MVEBU: Netgear RN102: Use Hardware BCH ECC

[Arnaud Ebalard]

Hi,

Ezequiel Garcia  writes:

> (Fixing Cc list: dropping devicetree guys, and adding Brian and MTD instead)
>
> On 05 Sep 04:23 PM, klightsp...@killerwolves.net wrote:
>> The bootloader on the Netgear ReadyNAS RN102 uses Hardware BCH ECC
>> (strength = 4), while the pxa3xx NAND driver by default uses 
>> Hamming ECC (strength = 1).
>> 
>
> Hm, I guess the device (Hynix H27U1G8F2BTR) does not support ONFI,
> and the kernel is just taking the legacy ECC. The flash specs makes no
> mention to ONFI, so probably no ONFI here.
>
>> This patch changes the ECC mode on these machines to match that
>> of the bootloader and of the stock firmware, so that for example
>> updating the kernel is possible without requiring a serial
>> connection.
>> 
>> This patch depends on commit 5b3e507 (mtd: nand: pxa3xx: Use ECC
>> strength and step size devicetree binding)
>> 
>> Signed-off-by: Ben Peddell 
>
> Looks good to me, since Arnaud reports this is the correct ECC scheme:
> http://natisbad.org/NAS2/index.html#hw-nand
>
> Acked-by: Ezequiel Garcia 
>
> Thanks for the fix,

w/o the patch, you can write data to the flash using userland tools from
mtd-utils package (flash_erase and nandwrite); data can then be read
again using userland tools (say using dd). But - as reported by Ben - if
you nandwrite an uImage from userland, here is what you indeed get from
u-boot when you try and boot that image:

  root@humble:~# flash_erase /dev/mtd2 0 0
  Erasing 128 Kibyte @ 5e -- 100 % complete 
  
  root@humble:~# nandwrite -p /dev/mtd2 /tmp/uImage-3.16.1.rn102
  Writing data to block 0 at offset 0x0
  Writing data to block 1 at offset 0x2
  Writing data to block 2 at offset 0x4
  Writing data to block 3 at offset 0x6
  Writing data to block 4 at offset 0x8
  
  ...
  
  reboot 
  
  ...
  
  Marvell>> nand read 0x120 0x20 0x60
  
  NAND read: device 0 offset 0x20, size 0x60
   6291456 bytes read: OK
  
  Marvell>> bootm 0x120
  ## Booting kernel from Legacy Image at 0120 ...
 Image Name:   Linux-3.16.1.rn102
 Created:  2014-08-14  13:33:46 UTC
 Image Type:   ARM Linux Kernel Image (uncompressed)
 Data Size:4423998 Bytes =  4.2 MB
 Load Address: 8000
 Entry Point:  8000
 Verifying Checksum ... Bad Data CRC
  ERROR: can't get kernel image!
  

Now, w/ the patch submitted by Ben, here is what you get:

  With the patch applied, this indeed works has 
  ## Booting kernel from Legacy Image at 0120 ...
 Image Name:   Linux-3.16.1.rn102
 Created:  2014-09-05  20:25:34 UTC
 Image Type:   ARM Linux Kernel Image (uncompressed)
 Data Size:4424067 Bytes =  4.2 MB
 Load Address: 8000
 Entry Point:  8000
 Verifying Checksum ... OK
 Loading Kernel Image ... OK
  OK
  
  Starting kernel ...

i.e. it works.  

So, thanks for reporting this, Ben. I must confess I got used to update
my kernels from u-boot and did not take enough attention to that
aspect when I updated the .dts to add access to NAND after Ezequiel
wrote the NAND driver. I will take a look at RN104 and RN2120 to check
if something similar is needed for those two.

FWIW, you can add my:

 Tested-by: Arnaud Ebalard 
 
Additionally, Ezequiel, would anything prevent pushing the patch to
stable team (nand entry in .dts was added in 3.14):

 Fixes: 92beaccd8b49 ("ARM: mvebu: Enable NAND controller in ReadyNAS 102 .dts 
file")

Cheers,

a+
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: MVEBU: Netgear RN102: Use Hardware BCH ECC

[Arnaud Ebalard]

Hi,

Ezequiel Garcia ezequiel.gar...@free-electrons.com writes:

 (Fixing Cc list: dropping devicetree guys, and adding Brian and MTD instead)

 On 05 Sep 04:23 PM, klightsp...@killerwolves.net wrote:
 The bootloader on the Netgear ReadyNAS RN102 uses Hardware BCH ECC
 (strength = 4), while the pxa3xx NAND driver by default uses 
 Hamming ECC (strength = 1).
 

 Hm, I guess the device (Hynix H27U1G8F2BTR) does not support ONFI,
 and the kernel is just taking the legacy ECC. The flash specs makes no
 mention to ONFI, so probably no ONFI here.

 This patch changes the ECC mode on these machines to match that
 of the bootloader and of the stock firmware, so that for example
 updating the kernel is possible without requiring a serial
 connection.
 
 This patch depends on commit 5b3e507 (mtd: nand: pxa3xx: Use ECC
 strength and step size devicetree binding)
 
 Signed-off-by: Ben Peddell klightsp...@killerwolves.net

 Looks good to me, since Arnaud reports this is the correct ECC scheme:
 http://natisbad.org/NAS2/index.html#hw-nand

 Acked-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com

 Thanks for the fix,

w/o the patch, you can write data to the flash using userland tools from
mtd-utils package (flash_erase and nandwrite); data can then be read
again using userland tools (say using dd). But - as reported by Ben - if
you nandwrite an uImage from userland, here is what you indeed get from
u-boot when you try and boot that image:

  root@humble:~# flash_erase /dev/mtd2 0 0
  Erasing 128 Kibyte @ 5e -- 100 % complete 
  
  root@humble:~# nandwrite -p /dev/mtd2 /tmp/uImage-3.16.1.rn102
  Writing data to block 0 at offset 0x0
  Writing data to block 1 at offset 0x2
  Writing data to block 2 at offset 0x4
  Writing data to block 3 at offset 0x6
  Writing data to block 4 at offset 0x8
  
  ...
  
  reboot 
  
  ...
  
  Marvell nand read 0x120 0x20 0x60
  
  NAND read: device 0 offset 0x20, size 0x60
   6291456 bytes read: OK
  
  Marvell bootm 0x120
  ## Booting kernel from Legacy Image at 0120 ...
 Image Name:   Linux-3.16.1.rn102
 Created:  2014-08-14  13:33:46 UTC
 Image Type:   ARM Linux Kernel Image (uncompressed)
 Data Size:4423998 Bytes =  4.2 MB
 Load Address: 8000
 Entry Point:  8000
 Verifying Checksum ... Bad Data CRC
  ERROR: can't get kernel image!
  

Now, w/ the patch submitted by Ben, here is what you get:

  With the patch applied, this indeed works has 
  ## Booting kernel from Legacy Image at 0120 ...
 Image Name:   Linux-3.16.1.rn102
 Created:  2014-09-05  20:25:34 UTC
 Image Type:   ARM Linux Kernel Image (uncompressed)
 Data Size:4424067 Bytes =  4.2 MB
 Load Address: 8000
 Entry Point:  8000
 Verifying Checksum ... OK
 Loading Kernel Image ... OK
  OK
  
  Starting kernel ...

i.e. it works.  

So, thanks for reporting this, Ben. I must confess I got used to update
my kernels from u-boot and did not take enough attention to that
aspect when I updated the .dts to add access to NAND after Ezequiel
wrote the NAND driver. I will take a look at RN104 and RN2120 to check
if something similar is needed for those two.

FWIW, you can add my:

 Tested-by: Arnaud Ebalard a...@natisbad.org
 
Additionally, Ezequiel, would anything prevent pushing the patch to
stable team (nand entry in .dts was added in 3.14):

 Fixes: 92beaccd8b49 (ARM: mvebu: Enable NAND controller in ReadyNAS 102 .dts 
file)

Cheers,

a+
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [rtc-linux] Re: Can someone Ack and queue a patch for RTC subsytem?

[Arnaud Ebalard]

Hi,

Mark Brown  writes:

> On Thu, Dec 19, 2013 at 11:17:44PM +0100, Arnaud Ebalard wrote:
>
>> All NETGEAR ReadyNAS 102, 104 and 2120 have an ISL 12057 RTC chip which
>> is used as main RTC clock but can also provide alarm. But the alarm
>> interrupt line of the chip is *not* connected to the SoC. It is
>> connected to some power component and can be used to wake up the NAS
>> when it is completely off and the alarm rings.
>
> Can the PMIC or whatever function as an interrupt controller and report
> the interrupt on to the SoC?

I do not even know to which specific component the irq line of the chip
is connected. You can take a look at [1] to see what's on the PCB; if
you have an idea about which one could be a good candidate (TPS65251?),
I can try and check with an ohmmeter which pin is connected to confirm
your guess. Then, I could look at the datasheet (if any) to see if it
can relay the interrupt to the SoC (if the component is supported by
Linux kernel).

But, except if we can do what you propose, there are two problems at
hand:

 1) I cannot currently test the IRQ handler my changes would bring
 because it is not connected to the SoC on my platforms

 2) even if I find a solution for 1), noone ever provided any directions
 on what should be required to make some program like rtc-test.c happy on
 my platforms (alarm support but no interrupt from the RTC). e.g. some 
 refinements like the one introduced by c9f5c7e7a84f1b7 (rtc: rtc-spear:
 Provide flag for no support of UIE mode). I guess it should be fairly
 simple for someone w/ good knowledge of the RTC subsystem to tell what
 is needed. I do not have that knowledge and the documentation does not
 help.

Regarding 1), I am starting to wonder if the best way out would not be
for me to connect the interrupt line of the ISL12057 to one of the GPIO
line currently connected to the LCD on my RN104 (after having
disconnected the LCD) and change the function of the associated MPP on
the SoC to make it an interrupt line. Could that work w/o additional
hardware modification? What are my chances of killing the board?

But this is pointless if I do not get any clear directions about 2).

Cheers,

a+

[1]: http://natisbad.org/NAS2/index.html#hw
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [rtc-linux] Re: Can someone Ack and queue a patch for RTC subsytem?

[Arnaud Ebalard]

Hi,

Mark Brown broo...@kernel.org writes:

 On Thu, Dec 19, 2013 at 11:17:44PM +0100, Arnaud Ebalard wrote:

 All NETGEAR ReadyNAS 102, 104 and 2120 have an ISL 12057 RTC chip which
 is used as main RTC clock but can also provide alarm. But the alarm
 interrupt line of the chip is *not* connected to the SoC. It is
 connected to some power component and can be used to wake up the NAS
 when it is completely off and the alarm rings.

 Can the PMIC or whatever function as an interrupt controller and report
 the interrupt on to the SoC?

I do not even know to which specific component the irq line of the chip
is connected. You can take a look at [1] to see what's on the PCB; if
you have an idea about which one could be a good candidate (TPS65251?),
I can try and check with an ohmmeter which pin is connected to confirm
your guess. Then, I could look at the datasheet (if any) to see if it
can relay the interrupt to the SoC (if the component is supported by
Linux kernel).

But, except if we can do what you propose, there are two problems at
hand:

 1) I cannot currently test the IRQ handler my changes would bring
 because it is not connected to the SoC on my platforms

 2) even if I find a solution for 1), noone ever provided any directions
 on what should be required to make some program like rtc-test.c happy on
 my platforms (alarm support but no interrupt from the RTC). e.g. some 
 refinements like the one introduced by c9f5c7e7a84f1b7 (rtc: rtc-spear:
 Provide flag for no support of UIE mode). I guess it should be fairly
 simple for someone w/ good knowledge of the RTC subsystem to tell what
 is needed. I do not have that knowledge and the documentation does not
 help.

Regarding 1), I am starting to wonder if the best way out would not be
for me to connect the interrupt line of the ISL12057 to one of the GPIO
line currently connected to the LCD on my RN104 (after having
disconnected the LCD) and change the function of the associated MPP on
the SoC to make it an interrupt line. Could that work w/o additional
hardware modification? What are my chances of killing the board?

But this is pointless if I do not get any clear directions about 2).

Cheers,

a+

[1]: http://natisbad.org/NAS2/index.html#hw
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv7] rtc: Add support for Intersil ISL12057 I2C RTC chip

[Arnaud Ebalard]

Hi Andrew,

Andrew Morton  writes:

> On Thu, 19 Dec 2013 22:53:16 +0100 Arnaud Ebalard  wrote:
>
>> +static int isl12057_i2c_validate_chip(struct regmap *regmap)
>> +{
>> +u8 regs[ISL12057_MEM_MAP_LEN];
>> +u8 mask[ISL12057_MEM_MAP_LEN] = { 0x80, 0x80, 0x80, 0xf8,
>> +  0xc0, 0x60, 0x00, 0x00,
>> +  0x00, 0x00, 0x00, 0x00,
>> +  0x00, 0x00, 0x60, 0x7c };
>> +int ret, i;
>> +
>> +ret = regmap_bulk_read(regmap, 0, regs, ISL12057_MEM_MAP_LEN);
>> +if (ret)
>> +return ret;
>> +
>> +for (i = 0; i < ISL12057_MEM_MAP_LEN; ++i) {
>> +if (regs[i] & mask[i])  /* check if bits are cleared */
>> +return -ENODEV;
>> +}
>> +
>> +return 0;
>> +}
>
> When I build this for x86_64, mask[] is assembled on-stack at runtime:
>
>   leaq-48(%rbp), %r14 #, tmp130
>   xorl%esi, %esi  #
>   movl$16, %ecx   #,
>   movq%rax, %rdi  # regmap,
>   incq.LPBX1+552(%rip)# *.LPBX1
>   movb$-128, -64(%rbp)#, mask
>   movq%r14, %rdx  # tmp130,
>   movb$-128, -63(%rbp)#, mask
>   movb$-128, -62(%rbp)#, mask
>   movb$-8, -61(%rbp)  #, mask
>   movb$-64, -60(%rbp) #, mask
>   movb$96, -59(%rbp)  #, mask
>   movb$0, -58(%rbp)   #, mask
>   movb$0, -57(%rbp)   #, mask
>   movb$0, -56(%rbp)   #, mask
>   movb$0, -55(%rbp)   #, mask
>   movb$0, -54(%rbp)   #, mask
>   movb$0, -53(%rbp)   #, mask
>   movb$0, -52(%rbp)   #, mask
>   movb$0, -51(%rbp)   #, mask
>   movb$96, -50(%rbp)  #, mask
>   movb$124, -49(%rbp) #, mask
>   callregmap_bulk_read#
>
> If we make `mask' static const, that all gets done at compile time instead:
>
>   leaq-48(%rbp), %r14 #, tmp134
>   xorl%esi, %esi  #
>   movl$16, %ecx   #,
>   movq%rax, %rdi  # regmap,
>   incq.LPBX1+552(%rip)# *.LPBX1
>   movq%r14, %rdx  # tmp134,
>   callregmap_bulk_read#
>
> much nicer.

Damned. That's a good argument for a v8 ;-) Give me some minutes to
assemble one.

Cheers,

a+
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [rtc-linux] Re: Can someone Ack and queue a patch for RTC subsytem?

[Arnaud Ebalard]

Hi,

Alessandro Zummo  writes:

> On Thu, 19 Dec 2013 11:46:24 -0500
> Jason Cooper  wrote:
>
>> In the long term, should we seek out a co-maintainer for drivers/rtc?
>> Can anyone get a hold of Alessandro to get his opinion on this?
>
>  I'd surely appreciate if someone can take some time to give
>  a look to the patches. Most of them go thru subsystem's tree and, as
>  far as I can see, I saw very relevant comments and fixes in all those
>  years.

While I am at it, I wonder if you can give me some directions on the
following to add back alarm support to the ISL12057 on the specific
hardware I have.

All NETGEAR ReadyNAS 102, 104 and 2120 have an ISL 12057 RTC chip which
is used as main RTC clock but can also provide alarm. But the alarm
interrupt line of the chip is *not* connected to the SoC. It is
connected to some power component and can be used to wake up the NAS
when it is completely off and the alarm rings.

To me this kind of setup seems logical but it does not seem to be
directly supported by current RTC logic:

 - first, I cannot test an interrupt handler implementation I had
   written as the SoC will never receive any interrupt. This limits
   my ability to provide one to the driver.
 - what can/should be done in my .dts file to indicate that the
   device does not have any IRQ line connected (and hence no interrupt
   handler) to the SoC but still supports an alarm.

As a side note, the implementation I had was a working one on my
hardware (i.e. was able to wake up the device at a given time) but I had
to remove alarm code to get a basic driver accepted upstream.

To be honest, I tried and understand what RTC subsystem expects from
documentation and code w/o success. Any help appreciated on that topic.

Cheers,

a+
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Can someone Ack and queue a patch for RTC subsytem?

[Arnaud Ebalard]

Hi,

Alessandro Zummo  writes:

>> Do you want me to send a v7 w/ the .proc helper removed or leave
>> things as they are and Ack the patch as is?
>
>  Unless absolutely needed, I'd prefer if you can remove them
>  or move to sysfs.

Well, my helper provides info on control and status registers flags
(just like rtc-isl1208.c does), which are useful mainly for debug I
guess. If this can help pushing things forward, I will send a v7 later
today w/ the .proc helper removed from the patch.

Cheers,

a+

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Can someone Ack and queue a patch for RTC subsytem?

[Arnaud Ebalard]

Hi,

Jason Cooper  writes:

> On Thu, Dec 19, 2013 at 05:34:09PM +0100, Arnaud Ebalard wrote:
>> I have a very simple driver (support for reading and setting the time)
>> for a RTC chip (Intersil ISL 12057) but cannot find anyone to get it
>> Acked and queued for v3.14. In v3.14, there should be at least three
>> users of the driver (ReadyNAS 102, 104 and 2120) if I meet -rc5 cutoff
>> for associated .dts changes.
>
> The -rc5 cutoff isn't a hard line.  It's also mvebu-specific.  eg, We
> need things _posted_ a week or so before arm-soc's cutoff of -rc6 so we
> have time to get the pull request in.  If it needs to go through
> mvebu/arm-soc, once it's posted, you're good.

I understand. But I guess you will not (for valid reason) accept .dts
changes to reference a rtc driver that is not on good track towards
-next. This is the issue I try and solve.


>> I never heard of *listed* RTC maintainer during all the review process
>> on rtc-linux list (v0 sent in october); I dug the list archives and when
>> this previously happened, someone else (e.g. Andrew Morton) was kind
>> enough to handle the patches:
>> 
>>   http://www.spinics.net/lists/arm-kernel/msg292187.html
>
> Unfortunately, it doesn't look like Alessandro has been active for a
> while and Andrew Morton has indeed been picking up the slack.  S-o-B's
> confirm this.
>
> I haven't worked with Andrew enough to know his workflow, but I imagine
> he can take patches much closer to the merge window than we can.
>
>> I wonder if someone (Andrew? Stephen? Jason?) would be kind enough to
>> take care of the v6 I just sent [1].
>
> I don't mind routing it though mvebu/arm-soc since the only consumers
> are currently mvebu boards, but I'd like to hear from Andrew that this
> is ok.

I will do what you think is the best.

Cheers,

a+
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Can someone Ack and queue a patch for RTC subsytem?

[Arnaud Ebalard]

Hi,

Alessandro Zummo  writes:

> On Thu, 19 Dec 2013 17:34:09 +0100
> a...@natisbad.org (Arnaud Ebalard) wrote:
>
>> I never heard of *listed* RTC maintainer during all the review process
>> on rtc-linux list (v0 sent in october); I dug the list archives and when
>> this previously happened, someone else (e.g. Andrew Morton) was kind
>> enough to handle the patches:
>
>  Yes, Andrew usually pick those. 

I guess he should be put in the MAINTAINERS file then. Otherwise,
get_maintainer.pl script can not do its job correctly and people
end up thinking you should be the one handling those.


> I do not maintain a separate tree due to most RTCs being specifit to a
> subsytem. 

I do not understand: the chip is generic, i.e. this is not a RTC chip
specific to a given SoC (like rtc-mv.c is for instance). Can you be
more specific?


>>   http://www.spinics.net/lists/arm-kernel/msg292187.html
>
>  Regarding your patch, please do not add entries to /proc.
>  Use sysfs if you need.

Well, this is what is currently described in the documentation
(Documentation/rtc.txt), in drivers/rtc/rtc-test.c driver and what
many drivers do (AFAICT, 22/125).

Additionally, I only provide some additional info for an existing
file: the /proc entry is created by the drivers/rtc/class.c as
soon as someone selects CONFIG_RTC_INTF_PROC.

Do you want me to send a v7 w/ the .proc helper removed or leave
things as they are and Ack the patch as is?

Cheers,

a+
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Can someone Ack and queue a patch for RTC subsytem?

[Arnaud Ebalard]

Hi,

I have a very simple driver (support for reading and setting the time)
for a RTC chip (Intersil ISL 12057) but cannot find anyone to get it
Acked and queued for v3.14. In v3.14, there should be at least three
users of the driver (ReadyNAS 102, 104 and 2120) if I meet -rc5 cutoff
for associated .dts changes.

I never heard of *listed* RTC maintainer during all the review process
on rtc-linux list (v0 sent in october); I dug the list archives and when
this previously happened, someone else (e.g. Andrew Morton) was kind
enough to handle the patches:

  http://www.spinics.net/lists/arm-kernel/msg292187.html

I wonder if someone (Andrew? Stephen? Jason?) would be kind enough to
take care of the v6 I just sent [1].

It has been:

  Reviewed-by: Guenter Roeck 
  Reviewed-by: Mark Brown 

Cheers,

a+

[1]: http://patchwork.ozlabs.org/patch/303616/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Can someone Ack and queue a patch for RTC subsytem?

[Arnaud Ebalard]

Hi,

I have a very simple driver (support for reading and setting the time)
for a RTC chip (Intersil ISL 12057) but cannot find anyone to get it
Acked and queued for v3.14. In v3.14, there should be at least three
users of the driver (ReadyNAS 102, 104 and 2120) if I meet -rc5 cutoff
for associated .dts changes.

I never heard of *listed* RTC maintainer during all the review process
on rtc-linux list (v0 sent in october); I dug the list archives and when
this previously happened, someone else (e.g. Andrew Morton) was kind
enough to handle the patches:

  http://www.spinics.net/lists/arm-kernel/msg292187.html

I wonder if someone (Andrew? Stephen? Jason?) would be kind enough to
take care of the v6 I just sent [1].

It has been:

  Reviewed-by: Guenter Roeck li...@roeck-us.net
  Reviewed-by: Mark Brown brow...@linaro.org

Cheers,

a+

[1]: http://patchwork.ozlabs.org/patch/303616/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Can someone Ack and queue a patch for RTC subsytem?

[Arnaud Ebalard]

Hi,

Alessandro Zummo a.zu...@towertech.it writes:

 On Thu, 19 Dec 2013 17:34:09 +0100
 a...@natisbad.org (Arnaud Ebalard) wrote:

 I never heard of *listed* RTC maintainer during all the review process
 on rtc-linux list (v0 sent in october); I dug the list archives and when
 this previously happened, someone else (e.g. Andrew Morton) was kind
 enough to handle the patches:

  Yes, Andrew usually pick those. 

I guess he should be put in the MAINTAINERS file then. Otherwise,
get_maintainer.pl script can not do its job correctly and people
end up thinking you should be the one handling those.


 I do not maintain a separate tree due to most RTCs being specifit to a
 subsytem. 

I do not understand: the chip is generic, i.e. this is not a RTC chip
specific to a given SoC (like rtc-mv.c is for instance). Can you be
more specific?


   http://www.spinics.net/lists/arm-kernel/msg292187.html

  Regarding your patch, please do not add entries to /proc.
  Use sysfs if you need.

Well, this is what is currently described in the documentation
(Documentation/rtc.txt), in drivers/rtc/rtc-test.c driver and what
many drivers do (AFAICT, 22/125).

Additionally, I only provide some additional info for an existing
file: the /proc entry is created by the drivers/rtc/class.c as
soon as someone selects CONFIG_RTC_INTF_PROC.

Do you want me to send a v7 w/ the .proc helper removed or leave
things as they are and Ack the patch as is?

Cheers,

a+
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Can someone Ack and queue a patch for RTC subsytem?

[Arnaud Ebalard]

Hi,

Jason Cooper ja...@lakedaemon.net writes:

 On Thu, Dec 19, 2013 at 05:34:09PM +0100, Arnaud Ebalard wrote:
 I have a very simple driver (support for reading and setting the time)
 for a RTC chip (Intersil ISL 12057) but cannot find anyone to get it
 Acked and queued for v3.14. In v3.14, there should be at least three
 users of the driver (ReadyNAS 102, 104 and 2120) if I meet -rc5 cutoff
 for associated .dts changes.

 The -rc5 cutoff isn't a hard line.  It's also mvebu-specific.  eg, We
 need things _posted_ a week or so before arm-soc's cutoff of -rc6 so we
 have time to get the pull request in.  If it needs to go through
 mvebu/arm-soc, once it's posted, you're good.

I understand. But I guess you will not (for valid reason) accept .dts
changes to reference a rtc driver that is not on good track towards
-next. This is the issue I try and solve.


 I never heard of *listed* RTC maintainer during all the review process
 on rtc-linux list (v0 sent in october); I dug the list archives and when
 this previously happened, someone else (e.g. Andrew Morton) was kind
 enough to handle the patches:
 
   http://www.spinics.net/lists/arm-kernel/msg292187.html

 Unfortunately, it doesn't look like Alessandro has been active for a
 while and Andrew Morton has indeed been picking up the slack.  S-o-B's
 confirm this.

 I haven't worked with Andrew enough to know his workflow, but I imagine
 he can take patches much closer to the merge window than we can.

 I wonder if someone (Andrew? Stephen? Jason?) would be kind enough to
 take care of the v6 I just sent [1].

 I don't mind routing it though mvebu/arm-soc since the only consumers
 are currently mvebu boards, but I'd like to hear from Andrew that this
 is ok.

I will do what you think is the best.

Cheers,

a+
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Can someone Ack and queue a patch for RTC subsytem?

[Arnaud Ebalard]

Hi,

Alessandro Zummo a.zu...@towertech.it writes:

 Do you want me to send a v7 w/ the .proc helper removed or leave
 things as they are and Ack the patch as is?

  Unless absolutely needed, I'd prefer if you can remove them
  or move to sysfs.

Well, my helper provides info on control and status registers flags
(just like rtc-isl1208.c does), which are useful mainly for debug I
guess. If this can help pushing things forward, I will send a v7 later
today w/ the .proc helper removed from the patch.

Cheers,

a+

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [rtc-linux] Re: Can someone Ack and queue a patch for RTC subsytem?

[Arnaud Ebalard]

Hi,

Alessandro Zummo a.zu...@towertech.it writes:

 On Thu, 19 Dec 2013 11:46:24 -0500
 Jason Cooper ja...@lakedaemon.net wrote:

 In the long term, should we seek out a co-maintainer for drivers/rtc?
 Can anyone get a hold of Alessandro to get his opinion on this?

  I'd surely appreciate if someone can take some time to give
  a look to the patches. Most of them go thru subsystem's tree and, as
  far as I can see, I saw very relevant comments and fixes in all those
  years.

While I am at it, I wonder if you can give me some directions on the
following to add back alarm support to the ISL12057 on the specific
hardware I have.

All NETGEAR ReadyNAS 102, 104 and 2120 have an ISL 12057 RTC chip which
is used as main RTC clock but can also provide alarm. But the alarm
interrupt line of the chip is *not* connected to the SoC. It is
connected to some power component and can be used to wake up the NAS
when it is completely off and the alarm rings.

To me this kind of setup seems logical but it does not seem to be
directly supported by current RTC logic:

 - first, I cannot test an interrupt handler implementation I had
   written as the SoC will never receive any interrupt. This limits
   my ability to provide one to the driver.
 - what can/should be done in my .dts file to indicate that the
   device does not have any IRQ line connected (and hence no interrupt
   handler) to the SoC but still supports an alarm.

As a side note, the implementation I had was a working one on my
hardware (i.e. was able to wake up the device at a given time) but I had
to remove alarm code to get a basic driver accepted upstream.

To be honest, I tried and understand what RTC subsystem expects from
documentation and code w/o success. Any help appreciated on that topic.

Cheers,

a+
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv7] rtc: Add support for Intersil ISL12057 I2C RTC chip

[Arnaud Ebalard]

Hi Andrew,

Andrew Morton a...@linux-foundation.org writes:

 On Thu, 19 Dec 2013 22:53:16 +0100 Arnaud Ebalard a...@natisbad.org wrote:

 +static int isl12057_i2c_validate_chip(struct regmap *regmap)
 +{
 +u8 regs[ISL12057_MEM_MAP_LEN];
 +u8 mask[ISL12057_MEM_MAP_LEN] = { 0x80, 0x80, 0x80, 0xf8,
 +  0xc0, 0x60, 0x00, 0x00,
 +  0x00, 0x00, 0x00, 0x00,
 +  0x00, 0x00, 0x60, 0x7c };
 +int ret, i;
 +
 +ret = regmap_bulk_read(regmap, 0, regs, ISL12057_MEM_MAP_LEN);
 +if (ret)
 +return ret;
 +
 +for (i = 0; i  ISL12057_MEM_MAP_LEN; ++i) {
 +if (regs[i]  mask[i])  /* check if bits are cleared */
 +return -ENODEV;
 +}
 +
 +return 0;
 +}

 When I build this for x86_64, mask[] is assembled on-stack at runtime:

   leaq-48(%rbp), %r14 #, tmp130
   xorl%esi, %esi  #
   movl$16, %ecx   #,
   movq%rax, %rdi  # regmap,
   incq.LPBX1+552(%rip)# *.LPBX1
   movb$-128, -64(%rbp)#, mask
   movq%r14, %rdx  # tmp130,
   movb$-128, -63(%rbp)#, mask
   movb$-128, -62(%rbp)#, mask
   movb$-8, -61(%rbp)  #, mask
   movb$-64, -60(%rbp) #, mask
   movb$96, -59(%rbp)  #, mask
   movb$0, -58(%rbp)   #, mask
   movb$0, -57(%rbp)   #, mask
   movb$0, -56(%rbp)   #, mask
   movb$0, -55(%rbp)   #, mask
   movb$0, -54(%rbp)   #, mask
   movb$0, -53(%rbp)   #, mask
   movb$0, -52(%rbp)   #, mask
   movb$0, -51(%rbp)   #, mask
   movb$96, -50(%rbp)  #, mask
   movb$124, -49(%rbp) #, mask
   callregmap_bulk_read#

 If we make `mask' static const, that all gets done at compile time instead:

   leaq-48(%rbp), %r14 #, tmp134
   xorl%esi, %esi  #
   movl$16, %ecx   #,
   movq%rax, %rdi  # regmap,
   incq.LPBX1+552(%rip)# *.LPBX1
   movq%r14, %rdx  # tmp134,
   callregmap_bulk_read#

 much nicer.

Damned. That's a good argument for a v8 ;-) Give me some minutes to
assemble one.

Cheers,

a+
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] hwmon: add support for GMT G751 chip in lm75 driver

[Arnaud Ebalard]

Hi Guenter,

Guenter Roeck  writes:

> On Sat, Nov 09, 2013 at 06:39:14PM +0100, Arnaud Ebalard wrote:
>> 
>> This was tested on a NETGEAR ReadyNAS 2120 device (Marvell Armada XP
>> based board, via DT).
>> 
>> Signed-off-by: Arnaud Ebalard 
>
> Looks good. I'll apply it to my -next branch. Since I already sent my 
> pull request to Linus, this will only go in after -rc1, which I hope
> should be ok (unless Jean wants to pick it up for his pull request).

Perfect, thanks.


>> ---
>> Hi Guenter,
>> 
>> As a side note, I removed the hunk that was present in previous patch to
>> add gmt to the list of DT vendor prefixes because I noticed someone had
>> taken care: https://lkml.org/lkml/2013/9/12/365
>> 
>> For the records, here is what I get on my NAS with the attached patch:
>> 
>> root@thin:/sys# sensors
>> g762-i2c-0-3e
>> Adapter: mv64xxx_i2c adapter
>> fan1:5461 RPM  (div = 1)
>> 
>> g762-i2c-0-48
>> Adapter: mv64xxx_i2c adapter
>> fan1:5461 RPM  (div = 1)
>> 
>> g762-i2c-0-49
>> Adapter: mv64xxx_i2c adapter
>> fan1:5461 RPM  (div = 1)
>> 
> Those rpms are pretty high. Are the fans all really running that fast ?

Unlike the fans on NETGEAR ReadyNAS 102 and 104 which are Protechnic
MGT9212YB-025 92mmx92mm running at 3200 RPM max, the three fans in the
RN2120 are Protechnic MGT4012XB-O20, i.e. 40mmx40mm running at 8000 RPM
max. At least, this is the max RPM value I found on their website
(Search Products on left side of http://www.protechnic-us.com/en/) for
both devices.

When pushing one a bit, here is the max rotation speed I get:

 root@thin:/sys/bus/i2c/drivers/g762/0-003e# echo 9000 > fan1_target ; \
 sleep 5 ; cat fan1_input
 8057

which AFAICT validates current settings for G762 and fan combination.
Did I miss something?

Cheers,

a+
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] hwmon: add support for GMT G751 chip in lm75 driver

[Arnaud Ebalard]

This was tested on a NETGEAR ReadyNAS 2120 device (Marvell Armada XP
based board, via DT).

Signed-off-by: Arnaud Ebalard 
---
Hi Guenter,

As a side note, I removed the hunk that was present in previous patch to
add gmt to the list of DT vendor prefixes because I noticed someone had
taken care: https://lkml.org/lkml/2013/9/12/365

For the records, here is what I get on my NAS with the attached patch:

root@thin:/sys# sensors
g762-i2c-0-3e
Adapter: mv64xxx_i2c adapter
fan1:5461 RPM  (div = 1)

g762-i2c-0-48
Adapter: mv64xxx_i2c adapter
fan1:5461 RPM  (div = 1)

g762-i2c-0-49
Adapter: mv64xxx_i2c adapter
fan1:5461 RPM  (div = 1)

g751-i2c-0-4c
Adapter: mv64xxx_i2c adapter
temp1:+30.5°C  (high = +80.0°C, hyst = +75.0°C)

armada_thermal-virtual-0
Adapter: Virtual device
temp1:+34.2°C

root@thin:/sys/bus/i2c/drivers/lm75/0-004c# ls
driver  modalias  subsystemtemp1_max   uevent
hwmon   name  temp1_input  temp1_max_hyst

root@thin:/sys/bus/i2c/drivers/lm75/0-004c# dmesg | grep lm
[  120.960471] lm75 0-004c: hwmon3: sensor 'g751'


just by adding the following to the .dts:

g751: g751@4c {
compatible = "gmt,g751";
reg = <0x4c>;
};

Do not hesitate to tell me if I missed something.

Cheers,

a+

 Documentation/devicetree/bindings/i2c/trivial-devices.txt | 1 +
 drivers/hwmon/Kconfig | 1 +
 drivers/hwmon/lm75.c  | 3 +++
 3 files changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt 
b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
index ad6a738..c98e5a2 100644
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -35,6 +35,7 @@ fsl,mc13892   MC13892: Power Management Integrated 
Circuit (PMIC) for i.MX35/51
 fsl,mma8450MMA8450Q: Xtrinsic Low-power, 3-axis Xtrinsic 
Accelerometer
 fsl,mpr121 MPR121: Proximity Capacitive Touch Sensor Controller
 fsl,sgtl5000   SGTL5000: Ultra Low-Power Audio Codec
+gmt,g751   G751: Digital Temperature Sensor and Thermal Watchdog 
with Two-Wire Interface
 infineon,slb9635tt Infineon SLB9635 (Soft-) I2C TPM (old protocol, max 
100khz)
 infineon,slb9645tt Infineon SLB9645 I2C TPM (new protocol, max 400khz)
 maxim,ds1050   5 Bit Programmable, Pulse-Width Modulator
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index b3ab9d4..52d548f 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -656,6 +656,7 @@ config SENSORS_LM75
 
- Analog Devices ADT75
- Dallas Semiconductor DS75, DS1775 and DS7505
+   - Global Mixed-mode Technology (GMT) G751
- Maxim MAX6625 and MAX6626
- Microchip MCP980x
- National Semiconductor LM75, LM75A
diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index c03b490..7e3ef13 100644
--- a/drivers/hwmon/lm75.c
+++ b/drivers/hwmon/lm75.c
@@ -39,6 +39,7 @@ enum lm75_type {  /* keep sorted in alphabetical 
order */
ds1775,
ds75,
ds7505,
+   g751,
lm75,
lm75a,
max6625,
@@ -208,6 +209,7 @@ lm75_probe(struct i2c_client *client, const struct 
i2c_device_id *id)
data->resolution = 12;
data->sample_time = HZ / 4;
break;
+   case g751:
case lm75:
case lm75a:
data->resolution = 9;
@@ -296,6 +298,7 @@ static const struct i2c_device_id lm75_ids[] = {
{ "ds1775", ds1775, },
{ "ds75", ds75, },
{ "ds7505", ds7505, },
+   { "g751", g751, },
{ "lm75", lm75, },
{ "lm75a", lm75a, },
{ "max6625", max6625, },
-- 
1.8.4.rc3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv0] hwmon: Add support for GMT G751 Temp. Sensor and Thermal Watchdog

[Arnaud Ebalard]

Hi Guenter,

Guenter Roeck  writes:

>> Sadly (for me), you are not: I compared the GMT G751 datasheet to an
>> original (1996) National semiconductor LM75 datasheet and they are
>> identical. I mean both the structure and full content (text, diagrams,
>> etc) is the same. Lesson learned: next time I start a driver, I will ask
>> if it ressembles an existing supported chip beforehand.
>>
>
> Hi Arnaud,
>
> that is interesting; I thought it is Yet Another Clone, not really exactly
> the same chip.

If you want to compare:

http://www.ieap.uni-kiel.de/surface/ag-berndt/lehre/fpmc/ns/lm75.pdf
http://natisbad.org/NAS4/refs/GMT_G751.pdf

>>> Please use the lm75 driver and add the g751 parameters to it.
>>
>> I will test if the driver does indeed work as expected to drive the G751
>> and will send a patch to document compatibility w/ GMT G751 (Kconfig,
>> i2c_device_id struct and lm75_detect function). While I am at it, if you
>> see something in the patch I pushed which could be useful for current
>> lm75 driver (doc, sysfs, of_ part for polarity, ...), just tell me.
>>
>
> Depends on what you need. The fault_queue and mode sysfs attributes are 
> neither
> necessary nor  acceptable - hwmon has well defined attributes, and new ones
> are only added after discussion. If you _need_ to configure polarity,
> interrupt mode, or fault queue depth in your application to anything but
> the default, we might discuss adding those as devicetree properties.
> However, you would have to make sure that it does not negatively affect
> the other chips supported by the driver, and we should then discuss
> if other properties should be supported as well. Overall, I strongly suspect
> that the HW is happy with the default configuration. If so, we should just 
> leave
> it alone.

Let's keep lm75 in I2C trivial devices list.

> Power control (the shutdown attribute) should be handled through the PM
> subsystem; see CONFIG_PM / CONFIG_PM_SLEEP in other drivers. If your hardware
> can sleep (which may be somewhat unlikely for a NAS),

lm75 driver does have #ifdef CONFIG_PM (or am I missing something?), but
you are right, I don't think the NAS can take advantage of it ATM.

I just finished the a first version of a patch for lm75 to reference
g751. I'll send it in a separate email.

Anyway, thanks for the quick feedback.

Cheers,

a+
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv0] hwmon: Add support for GMT G751 Temp. Sensor and Thermal Watchdog

[Arnaud Ebalard]

Hi,

Guenter Roeck  writes:

> On 11/08/2013 03:31 PM, Arnaud Ebalard wrote:
>>
>> This patch adds support for GMT G751 Temperature Sensor and Thermal
>> Watchdog I2C chip. It has been tested via DT on a Netgear ReadyNAS
>> 2120 (Marvell Armada XP based ARM device).
>>
>> Signed-off-by: Arnaud Ebalard 
>
> Arnaud,
>
> unless I am missing something, this is just an lm75 with a different
> name. 

Sadly (for me), you are not: I compared the GMT G751 datasheet to an
original (1996) National semiconductor LM75 datasheet and they are
identical. I mean both the structure and full content (text, diagrams,
etc) is the same. Lesson learned: next time I start a driver, I will ask
if it ressembles an existing supported chip beforehand.

> Please use the lm75 driver and add the g751 parameters to it.

I will test if the driver does indeed work as expected to drive the G751
and will send a patch to document compatibility w/ GMT G751 (Kconfig,
i2c_device_id struct and lm75_detect function). While I am at it, if you
see something in the patch I pushed which could be useful for current
lm75 driver (doc, sysfs, of_ part for polarity, ...), just tell me.

Cheers,

a+
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv0] hwmon: Add support for GMT G751 Temp. Sensor and Thermal Watchdog

[Arnaud Ebalard]

Hi,

Guenter Roeck li...@roeck-us.net writes:

 On 11/08/2013 03:31 PM, Arnaud Ebalard wrote:

 This patch adds support for GMT G751 Temperature Sensor and Thermal
 Watchdog I2C chip. It has been tested via DT on a Netgear ReadyNAS
 2120 (Marvell Armada XP based ARM device).

 Signed-off-by: Arnaud Ebalard a...@natisbad.org

 Arnaud,

 unless I am missing something, this is just an lm75 with a different
 name. 

Sadly (for me), you are not: I compared the GMT G751 datasheet to an
original (1996) National semiconductor LM75 datasheet and they are
identical. I mean both the structure and full content (text, diagrams,
etc) is the same. Lesson learned: next time I start a driver, I will ask
if it ressembles an existing supported chip beforehand.

 Please use the lm75 driver and add the g751 parameters to it.

I will test if the driver does indeed work as expected to drive the G751
and will send a patch to document compatibility w/ GMT G751 (Kconfig,
i2c_device_id struct and lm75_detect function). While I am at it, if you
see something in the patch I pushed which could be useful for current
lm75 driver (doc, sysfs, of_ part for polarity, ...), just tell me.

Cheers,

a+
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv0] hwmon: Add support for GMT G751 Temp. Sensor and Thermal Watchdog

[Arnaud Ebalard]

Hi Guenter,

Guenter Roeck li...@roeck-us.net writes:

 Sadly (for me), you are not: I compared the GMT G751 datasheet to an
 original (1996) National semiconductor LM75 datasheet and they are
 identical. I mean both the structure and full content (text, diagrams,
 etc) is the same. Lesson learned: next time I start a driver, I will ask
 if it ressembles an existing supported chip beforehand.


 Hi Arnaud,

 that is interesting; I thought it is Yet Another Clone, not really exactly
 the same chip.

If you want to compare:

http://www.ieap.uni-kiel.de/surface/ag-berndt/lehre/fpmc/ns/lm75.pdf
http://natisbad.org/NAS4/refs/GMT_G751.pdf

 Please use the lm75 driver and add the g751 parameters to it.

 I will test if the driver does indeed work as expected to drive the G751
 and will send a patch to document compatibility w/ GMT G751 (Kconfig,
 i2c_device_id struct and lm75_detect function). While I am at it, if you
 see something in the patch I pushed which could be useful for current
 lm75 driver (doc, sysfs, of_ part for polarity, ...), just tell me.


 Depends on what you need. The fault_queue and mode sysfs attributes are 
 neither
 necessary nor  acceptable - hwmon has well defined attributes, and new ones
 are only added after discussion. If you _need_ to configure polarity,
 interrupt mode, or fault queue depth in your application to anything but
 the default, we might discuss adding those as devicetree properties.
 However, you would have to make sure that it does not negatively affect
 the other chips supported by the driver, and we should then discuss
 if other properties should be supported as well. Overall, I strongly suspect
 that the HW is happy with the default configuration. If so, we should just 
 leave
 it alone.

Let's keep lm75 in I2C trivial devices list.

 Power control (the shutdown attribute) should be handled through the PM
 subsystem; see CONFIG_PM / CONFIG_PM_SLEEP in other drivers. If your hardware
 can sleep (which may be somewhat unlikely for a NAS),

lm75 driver does have #ifdef CONFIG_PM (or am I missing something?), but
you are right, I don't think the NAS can take advantage of it ATM.

I just finished the a first version of a patch for lm75 to reference
g751. I'll send it in a separate email.

Anyway, thanks for the quick feedback.

Cheers,

a+
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] hwmon: add support for GMT G751 chip in lm75 driver

[Arnaud Ebalard]

This was tested on a NETGEAR ReadyNAS 2120 device (Marvell Armada XP
based board, via DT).

Signed-off-by: Arnaud Ebalard a...@natisbad.org
---
Hi Guenter,

As a side note, I removed the hunk that was present in previous patch to
add gmt to the list of DT vendor prefixes because I noticed someone had
taken care: https://lkml.org/lkml/2013/9/12/365

For the records, here is what I get on my NAS with the attached patch:

root@thin:/sys# sensors
g762-i2c-0-3e
Adapter: mv64xxx_i2c adapter
fan1:5461 RPM  (div = 1)

g762-i2c-0-48
Adapter: mv64xxx_i2c adapter
fan1:5461 RPM  (div = 1)

g762-i2c-0-49
Adapter: mv64xxx_i2c adapter
fan1:5461 RPM  (div = 1)

g751-i2c-0-4c
Adapter: mv64xxx_i2c adapter
temp1:+30.5°C  (high = +80.0°C, hyst = +75.0°C)

armada_thermal-virtual-0
Adapter: Virtual device
temp1:+34.2°C

root@thin:/sys/bus/i2c/drivers/lm75/0-004c# ls
driver  modalias  subsystemtemp1_max   uevent
hwmon   name  temp1_input  temp1_max_hyst

root@thin:/sys/bus/i2c/drivers/lm75/0-004c# dmesg | grep lm
[  120.960471] lm75 0-004c: hwmon3: sensor 'g751'


just by adding the following to the .dts:

g751: g751@4c {
compatible = gmt,g751;
reg = 0x4c;
};

Do not hesitate to tell me if I missed something.

Cheers,

a+

 Documentation/devicetree/bindings/i2c/trivial-devices.txt | 1 +
 drivers/hwmon/Kconfig | 1 +
 drivers/hwmon/lm75.c  | 3 +++
 3 files changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt 
b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
index ad6a738..c98e5a2 100644
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -35,6 +35,7 @@ fsl,mc13892   MC13892: Power Management Integrated 
Circuit (PMIC) for i.MX35/51
 fsl,mma8450MMA8450Q: Xtrinsic Low-power, 3-axis Xtrinsic 
Accelerometer
 fsl,mpr121 MPR121: Proximity Capacitive Touch Sensor Controller
 fsl,sgtl5000   SGTL5000: Ultra Low-Power Audio Codec
+gmt,g751   G751: Digital Temperature Sensor and Thermal Watchdog 
with Two-Wire Interface
 infineon,slb9635tt Infineon SLB9635 (Soft-) I2C TPM (old protocol, max 
100khz)
 infineon,slb9645tt Infineon SLB9645 I2C TPM (new protocol, max 400khz)
 maxim,ds1050   5 Bit Programmable, Pulse-Width Modulator
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index b3ab9d4..52d548f 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -656,6 +656,7 @@ config SENSORS_LM75
 
- Analog Devices ADT75
- Dallas Semiconductor DS75, DS1775 and DS7505
+   - Global Mixed-mode Technology (GMT) G751
- Maxim MAX6625 and MAX6626
- Microchip MCP980x
- National Semiconductor LM75, LM75A
diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index c03b490..7e3ef13 100644
--- a/drivers/hwmon/lm75.c
+++ b/drivers/hwmon/lm75.c
@@ -39,6 +39,7 @@ enum lm75_type {  /* keep sorted in alphabetical 
order */
ds1775,
ds75,
ds7505,
+   g751,
lm75,
lm75a,
max6625,
@@ -208,6 +209,7 @@ lm75_probe(struct i2c_client *client, const struct 
i2c_device_id *id)
data-resolution = 12;
data-sample_time = HZ / 4;
break;
+   case g751:
case lm75:
case lm75a:
data-resolution = 9;
@@ -296,6 +298,7 @@ static const struct i2c_device_id lm75_ids[] = {
{ ds1775, ds1775, },
{ ds75, ds75, },
{ ds7505, ds7505, },
+   { g751, g751, },
{ lm75, lm75, },
{ lm75a, lm75a, },
{ max6625, max6625, },
-- 
1.8.4.rc3

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] hwmon: add support for GMT G751 chip in lm75 driver

[Arnaud Ebalard]

Hi Guenter,

Guenter Roeck li...@roeck-us.net writes:

 On Sat, Nov 09, 2013 at 06:39:14PM +0100, Arnaud Ebalard wrote:
 
 This was tested on a NETGEAR ReadyNAS 2120 device (Marvell Armada XP
 based board, via DT).
 
 Signed-off-by: Arnaud Ebalard a...@natisbad.org

 Looks good. I'll apply it to my -next branch. Since I already sent my 
 pull request to Linus, this will only go in after -rc1, which I hope
 should be ok (unless Jean wants to pick it up for his pull request).

Perfect, thanks.


 ---
 Hi Guenter,
 
 As a side note, I removed the hunk that was present in previous patch to
 add gmt to the list of DT vendor prefixes because I noticed someone had
 taken care: https://lkml.org/lkml/2013/9/12/365
 
 For the records, here is what I get on my NAS with the attached patch:
 
 root@thin:/sys# sensors
 g762-i2c-0-3e
 Adapter: mv64xxx_i2c adapter
 fan1:5461 RPM  (div = 1)
 
 g762-i2c-0-48
 Adapter: mv64xxx_i2c adapter
 fan1:5461 RPM  (div = 1)
 
 g762-i2c-0-49
 Adapter: mv64xxx_i2c adapter
 fan1:5461 RPM  (div = 1)
 
 Those rpms are pretty high. Are the fans all really running that fast ?

Unlike the fans on NETGEAR ReadyNAS 102 and 104 which are Protechnic
MGT9212YB-025 92mmx92mm running at 3200 RPM max, the three fans in the
RN2120 are Protechnic MGT4012XB-O20, i.e. 40mmx40mm running at 8000 RPM
max. At least, this is the max RPM value I found on their website
(Search Products on left side of http://www.protechnic-us.com/en/) for
both devices.

When pushing one a bit, here is the max rotation speed I get:

 root@thin:/sys/bus/i2c/drivers/g762/0-003e# echo 9000  fan1_target ; \
 sleep 5 ; cat fan1_input
 8057

which AFAICT validates current settings for G762 and fan combination.
Did I miss something?

Cheers,

a+
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv0] hwmon: Add support for GMT G751 Temp. Sensor and Thermal Watchdog

[Arnaud Ebalard]

This patch adds support for GMT G751 Temperature Sensor and Thermal
Watchdog I2C chip. It has been tested via DT on a Netgear ReadyNAS
2120 (Marvell Armada XP based ARM device).

Signed-off-by: Arnaud Ebalard 
---
 Documentation/devicetree/bindings/hwmon/g751.txt   |  24 +
 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 Documentation/hwmon/g751   |  44 ++
 drivers/hwmon/Kconfig  |  11 +
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/g751.c   | 481 +
 include/linux/platform_data/g751.h |  35 ++
 7 files changed, 597 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/g751.txt
 create mode 100644 Documentation/hwmon/g751
 create mode 100644 drivers/hwmon/g751.c
 create mode 100644 include/linux/platform_data/g751.h

diff --git a/Documentation/devicetree/bindings/hwmon/g751.txt 
b/Documentation/devicetree/bindings/hwmon/g751.txt
new file mode 100644
index 000..ebec788
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/g751.txt
@@ -0,0 +1,24 @@
+GMT G751 Digital Temperature Sensor and Thermal Watchdog
+
+Required node properties:
+
+ - "compatible": must be either "gmt,g751"
+ - "reg": I2C bus address of the device
+
+Optional properties:
+
+ - "polarity": Over temperature Shutdown (OS) output polarity. Accepted values
+  are 0 and 1. 0 (the default) is used to make the output active
+  low. 1 makes the output active high.
+
+Additional information on operational parameters for the device is available
+in Documentation/hwmon/g751. A detailed datasheet for the device is available
+at http://natisbad.org/NAS4/refs/GMT_G751.pdf.
+
+Example g751 node:
+
+   g751: g751@4c {
+   compatible = "gmt,g751";
+   reg = <0x4c>;
+   polarity = <1>; /* OS output Active High */
+   };
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 2956800..634c35f 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -28,6 +28,7 @@ est   ESTeem Wireless Modems
 fslFreescale Semiconductor
 GEFanucGE Fanuc Intelligent Platforms Embedded Systems, Inc.
 gefGE Fanuc Intelligent Platforms Embedded Systems, Inc.
+gmtGlobal Mixed-mode Technology Inc.
 hisilicon  Hisilicon Limited.
 hp Hewlett Packard
 ibmInternational Business Machines (IBM)
diff --git a/Documentation/hwmon/g751 b/Documentation/hwmon/g751
new file mode 100644
index 000..3508d53
--- /dev/null
+++ b/Documentation/hwmon/g751
@@ -0,0 +1,44 @@
+Kernel driver g751
+==
+
+The GMT G751 is an I2C digital temperature sensor and thermal watchdog. For
+additional information, a detailed datasheet of the chip is available at
+http://natisbad.org/NAS4/refs/GMT_G751.pdf.
+
+sysfs bindings (found in a subdirectory of/sys/bus/i2c/drivers/g751/) are
+described below. They are available to the user to control the operation
+of the device. The main information provided by the device (temperature,
+via temp_input) is usually used by a userland daemon like fancontrol.
+
+Note that polarity of Over temperature Shutdown (OS) output is considered
+a hardware characteristics of the system and can be modified via devicetree
+bindings documented in Documentation/devicetree/bindings/hwmon/g751.txt or
+using a specific platform_data structure in board initialization file (see
+include/linux/platform_data/g751.h).
+
+temp_input: current temperature input value in millidegree Celsius. This
+  parameter is RO.
+
+thyst: defined Thyst value in millidegree Celsius. See 'mode' below for
+  details. Default value depends on G751 flavour (45000 for G751-1,
+  75000 for G751-2). This parameter is RW.
+
+tos: defined Tos value in millidegree Celsius. See 'mode' below for details.
+  Default value depends on G751 flavour (5 for G751-1, 8 for
+  G751-2). This parameter is RW.
+
+fault_queue: number of faults necessary to detect before setting OS output.
+  This can be used to avoid false tripping due to noise. Valid values
+  are 1 (default), 2, 4 and 6. This parameter is RW.
+
+mode: used to toggle between comparatore mode (0, default mode) and interrupt
+  mode (1). In comparator mode, the OS output behaves like a thermostat
+  and becomes active when temperature exceeds Tos limit. It then leaves
+  the active state when the temperature drops again below Thyst. In
+  interrupt mode, exceeding Tos also makes OS output active in which case
+  it will remain active until reading any register. It can then be 
activated
+  again only after temperature goes below Thyst. This parameter is RW.
+
+shutdown: when set to 1 (0 being the default), the G751 goes to low power
+  sh

[PATCHv0] hwmon: Add support for GMT G751 Temp. Sensor and Thermal Watchdog

[Arnaud Ebalard]

This patch adds support for GMT G751 Temperature Sensor and Thermal
Watchdog I2C chip. It has been tested via DT on a Netgear ReadyNAS
2120 (Marvell Armada XP based ARM device).

Signed-off-by: Arnaud Ebalard a...@natisbad.org
---
 Documentation/devicetree/bindings/hwmon/g751.txt   |  24 +
 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 Documentation/hwmon/g751   |  44 ++
 drivers/hwmon/Kconfig  |  11 +
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/g751.c   | 481 +
 include/linux/platform_data/g751.h |  35 ++
 7 files changed, 597 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/g751.txt
 create mode 100644 Documentation/hwmon/g751
 create mode 100644 drivers/hwmon/g751.c
 create mode 100644 include/linux/platform_data/g751.h

diff --git a/Documentation/devicetree/bindings/hwmon/g751.txt 
b/Documentation/devicetree/bindings/hwmon/g751.txt
new file mode 100644
index 000..ebec788
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/g751.txt
@@ -0,0 +1,24 @@
+GMT G751 Digital Temperature Sensor and Thermal Watchdog
+
+Required node properties:
+
+ - compatible: must be either gmt,g751
+ - reg: I2C bus address of the device
+
+Optional properties:
+
+ - polarity: Over temperature Shutdown (OS) output polarity. Accepted values
+  are 0 and 1. 0 (the default) is used to make the output active
+  low. 1 makes the output active high.
+
+Additional information on operational parameters for the device is available
+in Documentation/hwmon/g751. A detailed datasheet for the device is available
+at http://natisbad.org/NAS4/refs/GMT_G751.pdf.
+
+Example g751 node:
+
+   g751: g751@4c {
+   compatible = gmt,g751;
+   reg = 0x4c;
+   polarity = 1; /* OS output Active High */
+   };
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 2956800..634c35f 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -28,6 +28,7 @@ est   ESTeem Wireless Modems
 fslFreescale Semiconductor
 GEFanucGE Fanuc Intelligent Platforms Embedded Systems, Inc.
 gefGE Fanuc Intelligent Platforms Embedded Systems, Inc.
+gmtGlobal Mixed-mode Technology Inc.
 hisilicon  Hisilicon Limited.
 hp Hewlett Packard
 ibmInternational Business Machines (IBM)
diff --git a/Documentation/hwmon/g751 b/Documentation/hwmon/g751
new file mode 100644
index 000..3508d53
--- /dev/null
+++ b/Documentation/hwmon/g751
@@ -0,0 +1,44 @@
+Kernel driver g751
+==
+
+The GMT G751 is an I2C digital temperature sensor and thermal watchdog. For
+additional information, a detailed datasheet of the chip is available at
+http://natisbad.org/NAS4/refs/GMT_G751.pdf.
+
+sysfs bindings (found in a subdirectory of/sys/bus/i2c/drivers/g751/) are
+described below. They are available to the user to control the operation
+of the device. The main information provided by the device (temperature,
+via temp_input) is usually used by a userland daemon like fancontrol.
+
+Note that polarity of Over temperature Shutdown (OS) output is considered
+a hardware characteristics of the system and can be modified via devicetree
+bindings documented in Documentation/devicetree/bindings/hwmon/g751.txt or
+using a specific platform_data structure in board initialization file (see
+include/linux/platform_data/g751.h).
+
+temp_input: current temperature input value in millidegree Celsius. This
+  parameter is RO.
+
+thyst: defined Thyst value in millidegree Celsius. See 'mode' below for
+  details. Default value depends on G751 flavour (45000 for G751-1,
+  75000 for G751-2). This parameter is RW.
+
+tos: defined Tos value in millidegree Celsius. See 'mode' below for details.
+  Default value depends on G751 flavour (5 for G751-1, 8 for
+  G751-2). This parameter is RW.
+
+fault_queue: number of faults necessary to detect before setting OS output.
+  This can be used to avoid false tripping due to noise. Valid values
+  are 1 (default), 2, 4 and 6. This parameter is RW.
+
+mode: used to toggle between comparatore mode (0, default mode) and interrupt
+  mode (1). In comparator mode, the OS output behaves like a thermostat
+  and becomes active when temperature exceeds Tos limit. It then leaves
+  the active state when the temperature drops again below Thyst. In
+  interrupt mode, exceeding Tos also makes OS output active in which case
+  it will remain active until reading any register. It can then be 
activated
+  again only after temperature goes below Thyst. This parameter is RW.
+
+shutdown: when set to 1 (0 being the default), the G751 goes to low power
+  shutdown mode. Placing G751 in shutdown mode also has

Re: [PATCH] net: mv643xx_eth: Add missing phy_addr_set in DT mode

[Arnaud Ebalard]

Hi,

Sebastian Hesselbarth  writes:

> On 11/05/2013 11:12 PM, Arnaud Ebalard wrote:
>> Hi Jason,
>>
>> Jason Gunthorpe  writes:
>>
>>> Commit cc9d4598 'net: mv643xx_eth: use of_phy_connect if phy_node
>>> present' made the call to phy_scan optional, if the DT has a link to
>>> the phy node.
>>>
>>> However phy_scan has the side effect of calling phy_addr_set, which
>>> writes the phy MDIO address to the ethernet controller. If phy_addr_set
>>> is not called, and the bootloader has not set the correct address then
>>> the driver will fail to function.
>>
>> Thanks *a lot* for fixing this one! I had the issue on my ReadyNAS 102
>> (Armada 370 based) which I had put on a todo list and temporarily
>
> Erm, just to make sure: Armada 370 isn't using mv643xx_eth but mvneta,
> are you sure it is (was) related to Jason's fix?

Thanks for pointing this, Sebastian and my apologies for the noise.
Jason's fix is indeed for a file which is not compiled for my RN102.

As the problem perfectly matched the issue I had and current kernel w/
the patch applied does indeed fix it, I did not try and do the test w/o
the patch applied. It would have showed the problem was fixed by
something else in 3.12. Well, I spent some time digging the changes on
mvneta.c and: 

commit 714086029116b6b0a34e67ba1dd2f0d1cf26770c
Author: Thomas Petazzoni 
Date:   Wed Sep 4 16:21:18 2013 +0200

net: mvneta: properly disable HW PHY polling and ensure adjust_link() works

This commit fixes a long-standing bug that has been reported by many
users: on some Armada 370 platforms, only the network interface that
has been used in U-Boot to tftp the kernel works properly in
Linux. The other network interfaces can see a 'link up', but are
unable to transmit data. The reports were generally made on the Armada
370-based Mirabox, but have also been given on the Armada 370-RD
board.

[SNIP]

$ git tag --contains 714086029116
v3.12
v3.12-rc1
v3.12-rc2
v3.12-rc3
v3.12-rc4
v3.12-rc5
v3.12-rc6
v3.12-rc7

So the problem was indeed fixed at the beginning of 3.12 series by Thomas.

Anyway, my bad and thanks again for pointing it out.

Cheers,

a+
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net: mv643xx_eth: Add missing phy_addr_set in DT mode

[Arnaud Ebalard]

Hi Jason,

Jason Gunthorpe  writes:

> Commit cc9d4598 'net: mv643xx_eth: use of_phy_connect if phy_node
> present' made the call to phy_scan optional, if the DT has a link to
> the phy node.
>
> However phy_scan has the side effect of calling phy_addr_set, which
> writes the phy MDIO address to the ethernet controller. If phy_addr_set
> is not called, and the bootloader has not set the correct address then
> the driver will fail to function.

Thanks *a lot* for fixing this one! I had the issue on my ReadyNAS 102
(Armada 370 based) which I had put on a todo list and temporarily
workarounded by including a 'ping whatever' call in my u-boot env in
order to force it to do the init. Without it, I was unable to properly
use the interface. With your fix, after multiple reboots to test it,
everything works as expected. So, FWIW: 

Tested-by: Arnaud Ebalard 

Cheers,

a+
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net: mv643xx_eth: Add missing phy_addr_set in DT mode

[Arnaud Ebalard]

Hi Jason,

Jason Gunthorpe jguntho...@obsidianresearch.com writes:

 Commit cc9d4598 'net: mv643xx_eth: use of_phy_connect if phy_node
 present' made the call to phy_scan optional, if the DT has a link to
 the phy node.

 However phy_scan has the side effect of calling phy_addr_set, which
 writes the phy MDIO address to the ethernet controller. If phy_addr_set
 is not called, and the bootloader has not set the correct address then
 the driver will fail to function.

Thanks *a lot* for fixing this one! I had the issue on my ReadyNAS 102
(Armada 370 based) which I had put on a todo list and temporarily
workarounded by including a 'ping whatever' call in my u-boot env in
order to force it to do the init. Without it, I was unable to properly
use the interface. With your fix, after multiple reboots to test it,
everything works as expected. So, FWIW: 

Tested-by: Arnaud Ebalard a...@natisbad.org

Cheers,

a+
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net: mv643xx_eth: Add missing phy_addr_set in DT mode

[Arnaud Ebalard]

Hi,

Sebastian Hesselbarth sebastian.hesselba...@gmail.com writes:

 On 11/05/2013 11:12 PM, Arnaud Ebalard wrote:
 Hi Jason,

 Jason Gunthorpe jguntho...@obsidianresearch.com writes:

 Commit cc9d4598 'net: mv643xx_eth: use of_phy_connect if phy_node
 present' made the call to phy_scan optional, if the DT has a link to
 the phy node.

 However phy_scan has the side effect of calling phy_addr_set, which
 writes the phy MDIO address to the ethernet controller. If phy_addr_set
 is not called, and the bootloader has not set the correct address then
 the driver will fail to function.

 Thanks *a lot* for fixing this one! I had the issue on my ReadyNAS 102
 (Armada 370 based) which I had put on a todo list and temporarily

 Erm, just to make sure: Armada 370 isn't using mv643xx_eth but mvneta,
 are you sure it is (was) related to Jason's fix?

Thanks for pointing this, Sebastian and my apologies for the noise.
Jason's fix is indeed for a file which is not compiled for my RN102.

As the problem perfectly matched the issue I had and current kernel w/
the patch applied does indeed fix it, I did not try and do the test w/o
the patch applied. It would have showed the problem was fixed by
something else in 3.12. Well, I spent some time digging the changes on
mvneta.c and: 

commit 714086029116b6b0a34e67ba1dd2f0d1cf26770c
Author: Thomas Petazzoni thomas.petazz...@free-electrons.com
Date:   Wed Sep 4 16:21:18 2013 +0200

net: mvneta: properly disable HW PHY polling and ensure adjust_link() works

This commit fixes a long-standing bug that has been reported by many
users: on some Armada 370 platforms, only the network interface that
has been used in U-Boot to tftp the kernel works properly in
Linux. The other network interfaces can see a 'link up', but are
unable to transmit data. The reports were generally made on the Armada
370-based Mirabox, but have also been given on the Armada 370-RD
board.

[SNIP]

$ git tag --contains 714086029116
v3.12
v3.12-rc1
v3.12-rc2
v3.12-rc3
v3.12-rc4
v3.12-rc5
v3.12-rc6
v3.12-rc7

So the problem was indeed fixed at the beginning of 3.12 series by Thomas.

Anyway, my bad and thanks again for pointing it out.

Cheers,

a+
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 5/7] ARM: kirkwood: remove redundant DT board files

[Arnaud Ebalard]

Hi Sebastian,

Sebastian Hesselbarth  writes:

> With DT support for mv643xx_eth board specific init for some boards now
> is unneccessary. Remove those board files, Kconfig entries, and
> corresponding entries in kirkwood_defconfig.

Applying above your set an old quilt cleaning patch Jason asked at some
point, it became empty except for arch/arm/mach_kirkwood/common.h in
which some declarations were left behind. If this is correct, can you
just merge the hunks below in your 5/7 in next round?

AFAICT, only dnskw_init() remains, which matches the list of board-*.c
files in arch/arm/mach_kirkwood/ (i.e. board-dt.c and board-dnskw.c).

Cheers,

a+

Signed-off-by: Arnaud Ebalard 
---
 arch/arm/mach-kirkwood/common.h | 108 
 1 file changed, 108 deletions(-)

diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-kirkwood/common.h
index 1c09f3f..1cbdd2b 100644
--- a/arch/arm/mach-kirkwood/common.h
+++ b/arch/arm/mach-kirkwood/common.h
@@ -57,26 +57,6 @@ void kirkwood_restart(char, const char *);
 void kirkwood_clk_init(void);
 
 /* board init functions for boards not fully converted to fdt */
-#ifdef CONFIG_MACH_DREAMPLUG_DT
-void dreamplug_init(void);
-#else
-static inline void dreamplug_init(void) {};
-#endif
-#ifdef CONFIG_MACH_GURUPLUG_DT
-void guruplug_dt_init(void);
-#else
-static inline void guruplug_dt_init(void) {};
-#endif
-#ifdef CONFIG_MACH_SHEEVAPLUG_DT
-void sheevaplug_dt_init(void);
-#else
-static inline void sheevaplug_dt_init(void) {};
-#endif
-#ifdef CONFIG_MACH_TS219_DT
-void qnap_dt_ts219_init(void);
-#else
-static inline void qnap_dt_ts219_init(void) {};
-#endif
 
 #ifdef CONFIG_MACH_DLINK_KIRKWOOD_DT
 void dnskw_init(void);
@@ -84,94 +64,6 @@ void dnskw_init(void);
 static inline void dnskw_init(void) {};
 #endif
 
-#ifdef CONFIG_MACH_ICONNECT_DT
-void iconnect_init(void);
-#else
-static inline void iconnect_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_IB62X0_DT
-void ib62x0_init(void);
-#else
-static inline void ib62x0_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_DOCKSTAR_DT
-void dockstar_dt_init(void);
-#else
-static inline void dockstar_dt_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_GOFLEXNET_DT
-void goflexnet_init(void);
-#else
-static inline void goflexnet_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_LSXL_DT
-void lsxl_init(void);
-#else
-static inline void lsxl_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_IOMEGA_IX2_200_DT
-void iomega_ix2_200_init(void);
-#else
-static inline void iomega_ix2_200_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_KM_KIRKWOOD_DT
-void km_kirkwood_init(void);
-#else
-static inline void km_kirkwood_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_DB88F628X_BP_DT
-void db88f628x_init(void);
-#else
-static inline void db88f628x_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_MPLCEC4_DT
-void mplcec4_init(void);
-#else
-static inline void mplcec4_init(void) {};
-#endif
-
-#if defined(CONFIG_MACH_INETSPACE_V2_DT) || \
-   defined(CONFIG_MACH_NETSPACE_V2_DT) || \
-   defined(CONFIG_MACH_NETSPACE_MAX_V2_DT) || \
-   defined(CONFIG_MACH_NETSPACE_LITE_V2_DT) || \
-   defined(CONFIG_MACH_NETSPACE_MINI_V2_DT)
-void ns2_init(void);
-#else
-static inline void ns2_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_OPENBLOCKS_A6_DT
-void openblocks_a6_init(void);
-#else
-static inline void openblocks_a6_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_READYNAS_DT
-void netgear_readynas_init(void);
-#else
-static inline void netgear_readynas_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_TOPKICK_DT
-void usi_topkick_init(void);
-#else
-static inline void usi_topkick_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_CLOUDBOX_DT
-void cloudbox_init(void);
-#else
-static inline void cloudbox_init(void) {};
-#endif
-
 /* early init functions not converted to fdt yet */
 char *kirkwood_id(void);
 void kirkwood_l2_init(void);
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 5/7] ARM: kirkwood: remove redundant DT board files

[Arnaud Ebalard]

Hi Sebastian,

Sebastian Hesselbarth sebastian.hesselba...@gmail.com writes:

 With DT support for mv643xx_eth board specific init for some boards now
 is unneccessary. Remove those board files, Kconfig entries, and
 corresponding entries in kirkwood_defconfig.

Applying above your set an old quilt cleaning patch Jason asked at some
point, it became empty except for arch/arm/mach_kirkwood/common.h in
which some declarations were left behind. If this is correct, can you
just merge the hunks below in your 5/7 in next round?

AFAICT, only dnskw_init() remains, which matches the list of board-*.c
files in arch/arm/mach_kirkwood/ (i.e. board-dt.c and board-dnskw.c).

Cheers,

a+

Signed-off-by: Arnaud Ebalard a...@natisbad.org
---
 arch/arm/mach-kirkwood/common.h | 108 
 1 file changed, 108 deletions(-)

diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-kirkwood/common.h
index 1c09f3f..1cbdd2b 100644
--- a/arch/arm/mach-kirkwood/common.h
+++ b/arch/arm/mach-kirkwood/common.h
@@ -57,26 +57,6 @@ void kirkwood_restart(char, const char *);
 void kirkwood_clk_init(void);
 
 /* board init functions for boards not fully converted to fdt */
-#ifdef CONFIG_MACH_DREAMPLUG_DT
-void dreamplug_init(void);
-#else
-static inline void dreamplug_init(void) {};
-#endif
-#ifdef CONFIG_MACH_GURUPLUG_DT
-void guruplug_dt_init(void);
-#else
-static inline void guruplug_dt_init(void) {};
-#endif
-#ifdef CONFIG_MACH_SHEEVAPLUG_DT
-void sheevaplug_dt_init(void);
-#else
-static inline void sheevaplug_dt_init(void) {};
-#endif
-#ifdef CONFIG_MACH_TS219_DT
-void qnap_dt_ts219_init(void);
-#else
-static inline void qnap_dt_ts219_init(void) {};
-#endif
 
 #ifdef CONFIG_MACH_DLINK_KIRKWOOD_DT
 void dnskw_init(void);
@@ -84,94 +64,6 @@ void dnskw_init(void);
 static inline void dnskw_init(void) {};
 #endif
 
-#ifdef CONFIG_MACH_ICONNECT_DT
-void iconnect_init(void);
-#else
-static inline void iconnect_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_IB62X0_DT
-void ib62x0_init(void);
-#else
-static inline void ib62x0_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_DOCKSTAR_DT
-void dockstar_dt_init(void);
-#else
-static inline void dockstar_dt_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_GOFLEXNET_DT
-void goflexnet_init(void);
-#else
-static inline void goflexnet_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_LSXL_DT
-void lsxl_init(void);
-#else
-static inline void lsxl_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_IOMEGA_IX2_200_DT
-void iomega_ix2_200_init(void);
-#else
-static inline void iomega_ix2_200_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_KM_KIRKWOOD_DT
-void km_kirkwood_init(void);
-#else
-static inline void km_kirkwood_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_DB88F628X_BP_DT
-void db88f628x_init(void);
-#else
-static inline void db88f628x_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_MPLCEC4_DT
-void mplcec4_init(void);
-#else
-static inline void mplcec4_init(void) {};
-#endif
-
-#if defined(CONFIG_MACH_INETSPACE_V2_DT) || \
-   defined(CONFIG_MACH_NETSPACE_V2_DT) || \
-   defined(CONFIG_MACH_NETSPACE_MAX_V2_DT) || \
-   defined(CONFIG_MACH_NETSPACE_LITE_V2_DT) || \
-   defined(CONFIG_MACH_NETSPACE_MINI_V2_DT)
-void ns2_init(void);
-#else
-static inline void ns2_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_OPENBLOCKS_A6_DT
-void openblocks_a6_init(void);
-#else
-static inline void openblocks_a6_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_READYNAS_DT
-void netgear_readynas_init(void);
-#else
-static inline void netgear_readynas_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_TOPKICK_DT
-void usi_topkick_init(void);
-#else
-static inline void usi_topkick_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_CLOUDBOX_DT
-void cloudbox_init(void);
-#else
-static inline void cloudbox_init(void) {};
-#endif
-
 /* early init functions not converted to fdt yet */
 char *kirkwood_id(void);
 void kirkwood_l2_init(void);
-- 
1.8.3.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 12/13] ARM: kirkwood: remove redundant DT board files

[Arnaud Ebalard]

NU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include 
-#include 
-#include "common.h"
-
-void __init mplcec4_init(void)
-{
-}
-
-
-
Index: linux/arch/arm/mach-kirkwood/board-readynas.c
===
--- linux.orig/arch/arm/mach-kirkwood/board-readynas.c  2013-05-30 
23:38:53.652311676 +0200
+++ /dev/null   1970-01-01 00:00:00.0 +
@@ -1,21 +0,0 @@
-/*
- * NETGEAR ReadyNAS Duo v2 Board setup for drivers not already
- * converted to DT.
- *
- * Copyright (C) 2013, Arnaud EBALARD 
- *
- * 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; either version
- * 2 of the License, or (at your option) any later version.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include "common.h"
-
-void __init netgear_readynas_init(void)
-{
-}
Index: linux/arch/arm/mach-kirkwood/common.h
===
--- linux.orig/arch/arm/mach-kirkwood/common.h  2013-05-30 23:38:53.652311676 
+0200
+++ linux/arch/arm/mach-kirkwood/common.h   2013-05-30 23:38:53.648311656 
+0200
@@ -55,16 +55,6 @@
 void kirkwood_clk_init(void);
 
 /* board init functions for boards not fully converted to fdt */
-#ifdef CONFIG_MACH_DREAMPLUG_DT
-void dreamplug_init(void);
-#else
-static inline void dreamplug_init(void) {};
-#endif
-#ifdef CONFIG_MACH_GURUPLUG_DT
-void guruplug_dt_init(void);
-#else
-static inline void guruplug_dt_init(void) {};
-#endif
 #ifdef CONFIG_MACH_TS219_DT
 void qnap_dt_ts219_init(void);
 #else
@@ -77,94 +67,12 @@
 static inline void dnskw_init(void) {};
 #endif
 
-#ifdef CONFIG_MACH_ICONNECT_DT
-void iconnect_init(void);
-#else
-static inline void iconnect_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_IB62X0_DT
-void ib62x0_init(void);
-#else
-static inline void ib62x0_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_DOCKSTAR_DT
-void dockstar_dt_init(void);
-#else
-static inline void dockstar_dt_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_GOFLEXNET_DT
-void goflexnet_init(void);
-#else
-static inline void goflexnet_init(void) {};
-#endif
-
 #ifdef CONFIG_MACH_LSXL_DT
 void lsxl_init(void);
 #else
 static inline void lsxl_init(void) {};
 #endif
 
-#ifdef CONFIG_MACH_IOMEGA_IX2_200_DT
-void iomega_ix2_200_init(void);
-#else
-static inline void iomega_ix2_200_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_KM_KIRKWOOD_DT
-void km_kirkwood_init(void);
-#else
-static inline void km_kirkwood_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_DB88F628X_BP_DT
-void db88f628x_init(void);
-#else
-static inline void db88f628x_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_MPLCEC4_DT
-void mplcec4_init(void);
-#else
-static inline void mplcec4_init(void) {};
-#endif
-
-#if defined(CONFIG_MACH_INETSPACE_V2_DT) || \
-   defined(CONFIG_MACH_NETSPACE_V2_DT) || \
-   defined(CONFIG_MACH_NETSPACE_MAX_V2_DT) || \
-   defined(CONFIG_MACH_NETSPACE_LITE_V2_DT) || \
-   defined(CONFIG_MACH_NETSPACE_MINI_V2_DT)
-void ns2_init(void);
-#else
-static inline void ns2_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_OPENBLOCKS_A6_DT
-void openblocks_a6_init(void);
-#else
-static inline void openblocks_a6_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_READYNAS_DT
-void netgear_readynas_init(void);
-#else
-static inline void netgear_readynas_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_TOPKICK_DT
-void usi_topkick_init(void);
-#else
-static inline void usi_topkick_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_CLOUDBOX_DT
-void cloudbox_init(void);
-#else
-static inline void cloudbox_init(void) {};
-#endif
-
 /* early init functions not converted to fdt yet */
 char *kirkwood_id(void);
 void kirkwood_l2_init(void);
Index: linux/arch/arm/mach-kirkwood/Kconfig
===
--- linux.orig/arch/arm/mach-kirkwood/Kconfig   2013-05-30 23:38:53.652311676 
+0200
+++ linux/arch/arm/mach-kirkwood/Kconfig2013-05-30 23:38:53.648311656 
+0200
@@ -140,13 +140,6 @@
  Say 'Y' here if you want your kernel to support the
  Marvell Kirkwood using flattened device tree.
 
-config MACH_DB88F628X_BP_DT
-   bool "Marvell DB-88F628x-BP Development Board (Flattened Device Tree)"
-   help
- Say 'Y' here if you want your kernel to support the Marvell
- DB-88F6281-BP and DB-88F6282-BP Development Board (Flattened
- Device Tree).
-
 config MACH_DLINK_KIRKWOOD_DT
bool "D-Link Kirkwood-based NAS (Flattened Device Tree)"
select ARCH_KIRKWOOD_DT
@@ -163,22 +156,6 @@
  Buffalo Linkstation LS-XHL & LS-CHLv2 devices, using
  Flattened Device Tree.
 
-config MACH_MPLCEC4_DT
-   bool "MPL CEC4 (Flattened Device Tree)"
-   select ARCH_KIRKWOOD_DT
-  

Re: [PATCH v5 12/13] ARM: kirkwood: remove redundant DT board files

[Arnaud Ebalard]

Hi Jason and Sebastian,

Sebastian Hesselbarth  writes:

> With DT support for mv643xx_eth board specific init for some boards now
> is unneccessary. Remove those board files, Kconfig entries, and
> corresponding entries in kirkwood_defconfig.
>
> Signed-off-by: Sebastian Hesselbarth 
> ---
> Note: board-km_kirkwood.c is also removed, as Valentin Longchamp confirmed
> the lock-up is not caused by accessing clock gating registers but rather
> non-existent device registers. This will be addressed by dtsi separation
> for kirkwood and bobcat SoC variants.
>
> Changelog:
> v3->v4:
> - remove more boards that don't require board specific setup
>
> Cc: David Miller 
> Cc: Lennert Buytenhek 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: Benjamin Herrenschmidt 
> Cc: net...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  arch/arm/configs/kirkwood_defconfig   |   16 
>  arch/arm/mach-kirkwood/Kconfig|  117 
> -
>  arch/arm/mach-kirkwood/Makefile   |   16 
>  arch/arm/mach-kirkwood/board-dnskw.c  |7 --
>  arch/arm/mach-kirkwood/board-dockstar.c   |   32 ---
>  arch/arm/mach-kirkwood/board-dreamplug.c  |   35 
>  arch/arm/mach-kirkwood/board-dt.c |   62 +
>  arch/arm/mach-kirkwood/board-goflexnet.c  |   34 ---
>  arch/arm/mach-kirkwood/board-guruplug.c   |   33 ---
>  arch/arm/mach-kirkwood/board-ib62x0.c |   29 --
>  arch/arm/mach-kirkwood/board-iconnect.c   |   10 ---
>  arch/arm/mach-kirkwood/board-iomega_ix2_200.c |   34 ---
>  arch/arm/mach-kirkwood/board-km_kirkwood.c|   44 --
>  arch/arm/mach-kirkwood/board-lsxl.c   |   16 
>  arch/arm/mach-kirkwood/board-mplcec4.c|   14 ---
>  arch/arm/mach-kirkwood/board-ns2.c|   35 
>  arch/arm/mach-kirkwood/board-openblocks_a6.c  |   26 --
>  arch/arm/mach-kirkwood/board-readynas.c   |6 --

Just a stupid note: With Thomas ongoing work to get mvebu-pcie driver in
place and enabled for kirkwood, some boards setup files will also lose
their pcie init routines, which may allow you to kill those additonal
files soon.

For instance 6bd98481ab34 (arm: kirkwood: NETGEAR ReadyNAS Duo v2 init
PCIe via DT) currently sitting in jcooper/mvebu/pcie_kirkwood removes
the PCIE init routine in board-readynas.c, and yours remove ge00
init. With both applied, the whole file can go away.

AFAICT, this may be the case soon for:

 arch/arm/mach-kirkwood/board-iconnect.c   (36e5722089)
 arch/arm/mach-kirkwood/board-mplcec4.c(9470fbfb8d)
 arch/arm/mach-kirkwood/board-nsa310.c (40fa8e5da2)
 arch/arm/mach-kirkwood/board-readynas.c   (6bd98481ab)
 arch/arm/mach-kirkwood/board-ts219.c  (259e234608)

Anyway, thanks for this work Sebastian.

Cheers,

a+
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 12/13] ARM: kirkwood: remove redundant DT board files

[Arnaud Ebalard]

Hi Jason and Sebastian,

Sebastian Hesselbarth sebastian.hesselba...@gmail.com writes:

 With DT support for mv643xx_eth board specific init for some boards now
 is unneccessary. Remove those board files, Kconfig entries, and
 corresponding entries in kirkwood_defconfig.

 Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
 ---
 Note: board-km_kirkwood.c is also removed, as Valentin Longchamp confirmed
 the lock-up is not caused by accessing clock gating registers but rather
 non-existent device registers. This will be addressed by dtsi separation
 for kirkwood and bobcat SoC variants.

 Changelog:
 v3-v4:
 - remove more boards that don't require board specific setup

 Cc: David Miller da...@davemloft.net
 Cc: Lennert Buytenhek buyt...@wantstofly.org
 Cc: Jason Cooper ja...@lakedaemon.net
 Cc: Andrew Lunn and...@lunn.ch
 Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
 Cc: net...@vger.kernel.org
 Cc: linux-arm-ker...@lists.infradead.org
 Cc: linuxppc-...@lists.ozlabs.org
 Cc: linux-kernel@vger.kernel.org
 ---
  arch/arm/configs/kirkwood_defconfig   |   16 
  arch/arm/mach-kirkwood/Kconfig|  117 
 -
  arch/arm/mach-kirkwood/Makefile   |   16 
  arch/arm/mach-kirkwood/board-dnskw.c  |7 --
  arch/arm/mach-kirkwood/board-dockstar.c   |   32 ---
  arch/arm/mach-kirkwood/board-dreamplug.c  |   35 
  arch/arm/mach-kirkwood/board-dt.c |   62 +
  arch/arm/mach-kirkwood/board-goflexnet.c  |   34 ---
  arch/arm/mach-kirkwood/board-guruplug.c   |   33 ---
  arch/arm/mach-kirkwood/board-ib62x0.c |   29 --
  arch/arm/mach-kirkwood/board-iconnect.c   |   10 ---
  arch/arm/mach-kirkwood/board-iomega_ix2_200.c |   34 ---
  arch/arm/mach-kirkwood/board-km_kirkwood.c|   44 --
  arch/arm/mach-kirkwood/board-lsxl.c   |   16 
  arch/arm/mach-kirkwood/board-mplcec4.c|   14 ---
  arch/arm/mach-kirkwood/board-ns2.c|   35 
  arch/arm/mach-kirkwood/board-openblocks_a6.c  |   26 --
  arch/arm/mach-kirkwood/board-readynas.c   |6 --

Just a stupid note: With Thomas ongoing work to get mvebu-pcie driver in
place and enabled for kirkwood, some boards setup files will also lose
their pcie init routines, which may allow you to kill those additonal
files soon.

For instance 6bd98481ab34 (arm: kirkwood: NETGEAR ReadyNAS Duo v2 init
PCIe via DT) currently sitting in jcooper/mvebu/pcie_kirkwood removes
the PCIE init routine in board-readynas.c, and yours remove ge00
init. With both applied, the whole file can go away.

AFAICT, this may be the case soon for:

 arch/arm/mach-kirkwood/board-iconnect.c   (36e5722089)
 arch/arm/mach-kirkwood/board-mplcec4.c(9470fbfb8d)
 arch/arm/mach-kirkwood/board-nsa310.c (40fa8e5da2)
 arch/arm/mach-kirkwood/board-readynas.c   (6bd98481ab)
 arch/arm/mach-kirkwood/board-ts219.c  (259e234608)

Anyway, thanks for this work Sebastian.

Cheers,

a+
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 12/13] ARM: kirkwood: remove redundant DT board files

[Arnaud Ebalard]

.  This program is licensed as is without any
- * warranty of any kind, whether express or implied.
- */
-
-#include linux/kernel.h
-#include linux/init.h
-#include common.h
-
-void __init mplcec4_init(void)
-{
-}
-
-
-
Index: linux/arch/arm/mach-kirkwood/board-readynas.c
===
--- linux.orig/arch/arm/mach-kirkwood/board-readynas.c  2013-05-30 
23:38:53.652311676 +0200
+++ /dev/null   1970-01-01 00:00:00.0 +
@@ -1,21 +0,0 @@
-/*
- * NETGEAR ReadyNAS Duo v2 Board setup for drivers not already
- * converted to DT.
- *
- * Copyright (C) 2013, Arnaud EBALARD a...@natisbad.org
- *
- * 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; either version
- * 2 of the License, or (at your option) any later version.
- */
-
-#include linux/kernel.h
-#include linux/init.h
-#include linux/platform_device.h
-#include mach/kirkwood.h
-#include common.h
-
-void __init netgear_readynas_init(void)
-{
-}
Index: linux/arch/arm/mach-kirkwood/common.h
===
--- linux.orig/arch/arm/mach-kirkwood/common.h  2013-05-30 23:38:53.652311676 
+0200
+++ linux/arch/arm/mach-kirkwood/common.h   2013-05-30 23:38:53.648311656 
+0200
@@ -55,16 +55,6 @@
 void kirkwood_clk_init(void);
 
 /* board init functions for boards not fully converted to fdt */
-#ifdef CONFIG_MACH_DREAMPLUG_DT
-void dreamplug_init(void);
-#else
-static inline void dreamplug_init(void) {};
-#endif
-#ifdef CONFIG_MACH_GURUPLUG_DT
-void guruplug_dt_init(void);
-#else
-static inline void guruplug_dt_init(void) {};
-#endif
 #ifdef CONFIG_MACH_TS219_DT
 void qnap_dt_ts219_init(void);
 #else
@@ -77,94 +67,12 @@
 static inline void dnskw_init(void) {};
 #endif
 
-#ifdef CONFIG_MACH_ICONNECT_DT
-void iconnect_init(void);
-#else
-static inline void iconnect_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_IB62X0_DT
-void ib62x0_init(void);
-#else
-static inline void ib62x0_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_DOCKSTAR_DT
-void dockstar_dt_init(void);
-#else
-static inline void dockstar_dt_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_GOFLEXNET_DT
-void goflexnet_init(void);
-#else
-static inline void goflexnet_init(void) {};
-#endif
-
 #ifdef CONFIG_MACH_LSXL_DT
 void lsxl_init(void);
 #else
 static inline void lsxl_init(void) {};
 #endif
 
-#ifdef CONFIG_MACH_IOMEGA_IX2_200_DT
-void iomega_ix2_200_init(void);
-#else
-static inline void iomega_ix2_200_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_KM_KIRKWOOD_DT
-void km_kirkwood_init(void);
-#else
-static inline void km_kirkwood_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_DB88F628X_BP_DT
-void db88f628x_init(void);
-#else
-static inline void db88f628x_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_MPLCEC4_DT
-void mplcec4_init(void);
-#else
-static inline void mplcec4_init(void) {};
-#endif
-
-#if defined(CONFIG_MACH_INETSPACE_V2_DT) || \
-   defined(CONFIG_MACH_NETSPACE_V2_DT) || \
-   defined(CONFIG_MACH_NETSPACE_MAX_V2_DT) || \
-   defined(CONFIG_MACH_NETSPACE_LITE_V2_DT) || \
-   defined(CONFIG_MACH_NETSPACE_MINI_V2_DT)
-void ns2_init(void);
-#else
-static inline void ns2_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_OPENBLOCKS_A6_DT
-void openblocks_a6_init(void);
-#else
-static inline void openblocks_a6_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_READYNAS_DT
-void netgear_readynas_init(void);
-#else
-static inline void netgear_readynas_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_TOPKICK_DT
-void usi_topkick_init(void);
-#else
-static inline void usi_topkick_init(void) {};
-#endif
-
-#ifdef CONFIG_MACH_CLOUDBOX_DT
-void cloudbox_init(void);
-#else
-static inline void cloudbox_init(void) {};
-#endif
-
 /* early init functions not converted to fdt yet */
 char *kirkwood_id(void);
 void kirkwood_l2_init(void);
Index: linux/arch/arm/mach-kirkwood/Kconfig
===
--- linux.orig/arch/arm/mach-kirkwood/Kconfig   2013-05-30 23:38:53.652311676 
+0200
+++ linux/arch/arm/mach-kirkwood/Kconfig2013-05-30 23:38:53.648311656 
+0200
@@ -140,13 +140,6 @@
  Say 'Y' here if you want your kernel to support the
  Marvell Kirkwood using flattened device tree.
 
-config MACH_DB88F628X_BP_DT
-   bool Marvell DB-88F628x-BP Development Board (Flattened Device Tree)
-   help
- Say 'Y' here if you want your kernel to support the Marvell
- DB-88F6281-BP and DB-88F6282-BP Development Board (Flattened
- Device Tree).
-
 config MACH_DLINK_KIRKWOOD_DT
bool D-Link Kirkwood-based NAS (Flattened Device Tree)
select ARCH_KIRKWOOD_DT
@@ -163,22 +156,6 @@
  Buffalo Linkstation LS-XHL  LS-CHLv2 devices, using
  Flattened Device Tree.
 
-config MACH_MPLCEC4_DT
-   bool MPL CEC4 (Flattened Device Tree)
-   select ARCH_KIRKWOOD_DT