[PATCH 0/3] ARM: omap: fix 4.7 gpmc networking regression

[PATCH 0/3] ARM: omap: fix 4.7 gpmc networking regression

[Johan Hovold]

Networking is currently broken for Overo boards due to a regression in
4.7. I bisected it down to

	d2d00862dfbb ("memory: omap-gpmc: Support general purpose input
	for WAITPINs")

which changed how errors when probing gpmc child nodes are handled.
Instead of proceeding with setting up any other children as before, a
single error now aborts the whole process.

Due to an unrelated issue with a nand gpmc-node, this change broke
networking for Overo Tobi and other Overo boards with gpmc ethernet:

[    0.823364] omap-gpmc 6e000000.gpmc: GPMC revision 5.0
[    0.823822] gpmc_mem_init: disabling cs 0 mapped at 0x0-0x1000000
[    0.823974] gpiochip_find_base: found new base at 508
[    0.824096] gpio gpiochip6: (omap-gpmc): added GPIO chardev (254:6)
[    0.827148] gpiochip_setup_dev: registered GPIOs 508 to 511 on device: gpiochip6 (omap-gpmc)
[    0.827362] omap-gpmc 6e000000.gpmc: /ocp/gpmc at 6e000000/nand at 0,0 has malformed 'reg' property
[    0.827392] omap-gpmc 6e000000.gpmc: failed to probe DT children

This series restores the 4.6 behaviour of allowing probe of gpmc child
nodes to fail, and also fixes the problems with the Overo nand node.

Note that simply fixing the Overo NAND issue would fix the Overo
networking regression, but by restoring the 4.6 gpmc-probe behaviour
similar regressions on other OMAP systems are also avoided.

Johan


Johan Hovold (3):
  memory: omap-gpmc: allow probe of child nodes to fail
  ARM: dts: overo: fix gpmc nand cs0 range
  ARM: dts: overo: fix gpmc nand on boards with ethernet

 arch/arm/boot/dts/omap3-overo-base.dtsi             |  4 +++-
 .../arm/boot/dts/omap3-overo-chestnut43-common.dtsi |  2 --
 arch/arm/boot/dts/omap3-overo-tobi-common.dtsi      |  2 --
 arch/arm/boot/dts/omap3-overo-tobiduo-common.dtsi   |  3 ---
 drivers/memory/omap-gpmc.c                          | 21 +++++++--------------
 5 files changed, 10 insertions(+), 22 deletions(-)

-- 
2.7.3

[PATCH 1/3] memory: omap-gpmc: allow probe of child nodes to fail

[Johan Hovold]

A recent commit (inadvertently?) changed how failed probe of a gpmc
child node was handled. Instead of proceeding with setting up any other
children as before, a single error now aborts the whole process.

This change broke networking on some Overo boards due to probe failing
for an unrelated nand node. This second issue should obviously be
fixed, but let's restore the old behaviour of allowing child-node
probe to fail to avoid further similar breakage on other systems.

Fixes: d2d00862dfbb ("memory: omap-gpmc: Support general purpose input
for WAITPINs")

Signed-off-by: Johan Hovold <johan@kernel.org>
---
 drivers/memory/omap-gpmc.c | 21 +++++++--------------
 1 file changed, 7 insertions(+), 14 deletions(-)

diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index 15508df24e5d..73ec3200191e 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -2250,7 +2250,7 @@ static int gpmc_probe_dt(struct platform_device *pdev)
 	return 0;
 }
 
-static int gpmc_probe_dt_children(struct platform_device *pdev)
+static void gpmc_probe_dt_children(struct platform_device *pdev)
 {
 	int ret;
 	struct device_node *child;
@@ -2265,11 +2265,11 @@ static int gpmc_probe_dt_children(struct platform_device *pdev)
 		else
 			ret = gpmc_probe_generic_child(pdev, child);
 
-		if (ret)
-			return ret;
+		if (ret) {
+			dev_err(&pdev->dev, "failed to probe DT child '%s': %d\n",
+				child->name, ret);
+		}
 	}
-
-	return 0;
 }
 #else
 static int gpmc_probe_dt(struct platform_device *pdev)
@@ -2277,9 +2277,8 @@ static int gpmc_probe_dt(struct platform_device *pdev)
 	return 0;
 }
 
-static int gpmc_probe_dt_children(struct platform_device *pdev)
+static void gpmc_probe_dt_children(struct platform_device *pdev)
 {
-	return 0;
 }
 #endif
 
@@ -2372,16 +2371,10 @@ static int gpmc_probe(struct platform_device *pdev)
 		goto setup_irq_failed;
 	}
 
-	rc = gpmc_probe_dt_children(pdev);
-	if (rc < 0) {
-		dev_err(gpmc->dev, "failed to probe DT children\n");
-		goto dt_children_failed;
-	}
+	gpmc_probe_dt_children(pdev);
 
 	return 0;
 
-dt_children_failed:
-	gpmc_free_irq(gpmc);
 setup_irq_failed:
 	gpmc_gpio_exit(gpmc);
 gpio_init_failed:
-- 
2.7.3

[PATCH 2/3] ARM: dts: overo: fix gpmc nand cs0 range

[Johan Hovold]

The gpmc ranges property for NAND at CS0 has been broken since it was
first added.

This currently prevents the nand gpmc child node from being probed:

	omap-gpmc 6e000000.gpmc: /ocp/gpmc at 6e000000/nand at 0,0 has
	malformed 'reg' property

and consequently the NAND device from being registered.

Fixes: 98ce6007efb4 ("ARM: dts: overo: Support PoP NAND")
Cc: stable <stable@vger.kernel.org>	# 4.3
Signed-off-by: Johan Hovold <johan@kernel.org>
---
 arch/arm/boot/dts/omap3-overo-base.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-overo-base.dtsi b/arch/arm/boot/dts/omap3-overo-base.dtsi
index de256fa8da48..b15c435439fb 100644
--- a/arch/arm/boot/dts/omap3-overo-base.dtsi
+++ b/arch/arm/boot/dts/omap3-overo-base.dtsi
@@ -223,7 +223,7 @@
 };
 
 &gpmc {
-	ranges = <0 0 0x00000000 0x20000000>;
+	ranges = <0 0 0x30000000 0x1000000>;	/* CS0 */
 
 	nand at 0,0 {
 		compatible = "ti,omap2-nand";
-- 
2.7.3

[PATCH 3/3] ARM: dts: overo: fix gpmc nand on boards with ethernet

[Johan Hovold]

The gpmc ranges property for NAND at CS0 was being overridden by later
includes that defined gpmc ethernet nodes, effectively breaking NAND on
these systems:

	omap-gpmc 6e000000.gpmc: /ocp/gpmc at 6e000000/nand at 0,0 has
	malformed 'reg' property

Instead of redefining the NAND range in every such dtsi, define all
currently used ranges in omap3-overo-base.dtsi.

Fixes: 98ce6007efb4 ("ARM: dts: overo: Support PoP NAND")
Cc: stable <stable@vger.kernel.org> # 4.3
Signed-off-by: Johan Hovold <johan@kernel.org>
---
 arch/arm/boot/dts/omap3-overo-base.dtsi              | 4 +++-
 arch/arm/boot/dts/omap3-overo-chestnut43-common.dtsi | 2 --
 arch/arm/boot/dts/omap3-overo-tobi-common.dtsi       | 2 --
 arch/arm/boot/dts/omap3-overo-tobiduo-common.dtsi    | 3 ---
 4 files changed, 3 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-overo-base.dtsi b/arch/arm/boot/dts/omap3-overo-base.dtsi
index b15c435439fb..3e946cac55f3 100644
--- a/arch/arm/boot/dts/omap3-overo-base.dtsi
+++ b/arch/arm/boot/dts/omap3-overo-base.dtsi
@@ -223,7 +223,9 @@
 };
 
 &gpmc {
-	ranges = <0 0 0x30000000 0x1000000>;	/* CS0 */
+	ranges = <0 0 0x30000000 0x1000000>,	/* CS0 */
+		 <4 0 0x2b000000 0x1000000>,	/* CS4 */
+		 <5 0 0x2c000000 0x1000000>;	/* CS5 */
 
 	nand at 0,0 {
 		compatible = "ti,omap2-nand";
diff --git a/arch/arm/boot/dts/omap3-overo-chestnut43-common.dtsi b/arch/arm/boot/dts/omap3-overo-chestnut43-common.dtsi
index 7df27926ead2..4f4c6efbd518 100644
--- a/arch/arm/boot/dts/omap3-overo-chestnut43-common.dtsi
+++ b/arch/arm/boot/dts/omap3-overo-chestnut43-common.dtsi
@@ -55,8 +55,6 @@
 #include "omap-gpmc-smsc9221.dtsi"
 
 &gpmc {
-	ranges = <5 0 0x2c000000 0x1000000>;	/* CS5 */
-
 	ethernet at gpmc {
 		reg = <5 0 0xff>;
 		interrupt-parent = <&gpio6>;
diff --git a/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi b/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi
index 9e24b6a1d07b..1b304e2f1bd2 100644
--- a/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi
+++ b/arch/arm/boot/dts/omap3-overo-tobi-common.dtsi
@@ -27,8 +27,6 @@
 #include "omap-gpmc-smsc9221.dtsi"
 
 &gpmc {
-	ranges = <5 0 0x2c000000 0x1000000>;	/* CS5 */
-
 	ethernet at gpmc {
 		reg = <5 0 0xff>;
 		interrupt-parent = <&gpio6>;
diff --git a/arch/arm/boot/dts/omap3-overo-tobiduo-common.dtsi b/arch/arm/boot/dts/omap3-overo-tobiduo-common.dtsi
index 334109e14613..82e98ee3023a 100644
--- a/arch/arm/boot/dts/omap3-overo-tobiduo-common.dtsi
+++ b/arch/arm/boot/dts/omap3-overo-tobiduo-common.dtsi
@@ -15,9 +15,6 @@
 #include "omap-gpmc-smsc9221.dtsi"
 
 &gpmc {
-	ranges = <4 0 0x2b000000 0x1000000>,	/* CS4 */
-		 <5 0 0x2c000000 0x1000000>;	/* CS5 */
-
 	smsc1: ethernet at gpmc {
 		reg = <5 0 0xff>;
 		interrupt-parent = <&gpio6>;
-- 
2.7.3

[PATCH 0/3] ARM: omap: fix 4.7 gpmc networking regression

[Tony Lindgren]

* Johan Hovold <johan@kernel.org> [160724 05:11]:
> Networking is currently broken for Overo boards due to a regression in
> 4.7. I bisected it down to
> 
> 	d2d00862dfbb ("memory: omap-gpmc: Support general purpose input
> 	for WAITPINs")
...

> Note that simply fixing the Overo NAND issue would fix the Overo
> networking regression, but by restoring the 4.6 gpmc-probe behaviour
> similar regressions on other OMAP systems are also avoided.

Roger, got a better fix in mind?

Regards,

Tony

[PATCH 0/3] ARM: omap: fix 4.7 gpmc networking regression

[Roger Quadros]

On 02/08/16 13:35, Tony Lindgren wrote:
> * Johan Hovold <johan@kernel.org> [160724 05:11]:
>> Networking is currently broken for Overo boards due to a regression in
>> 4.7. I bisected it down to
>>
>> 	d2d00862dfbb ("memory: omap-gpmc: Support general purpose input
>> 	for WAITPINs")
> ...
> 
>> Note that simply fixing the Overo NAND issue would fix the Overo
>> networking regression, but by restoring the 4.6 gpmc-probe behaviour
>> similar regressions on other OMAP systems are also avoided.
> 
> Roger, got a better fix in mind?
> 

Nope. I'll take patch 1 in my omap-gpmc queue for v4.8.
Thanks for the fixes Johan.

cheers,
-roger

[PATCH 0/3] ARM: omap: fix 4.7 gpmc networking regression

[Johan Hovold]

On Wed, Aug 03, 2016 at 10:46:24AM +0300, Roger Quadros wrote:
> On 02/08/16 13:35, Tony Lindgren wrote:
> > * Johan Hovold <johan@kernel.org> [160724 05:11]:
> >> Networking is currently broken for Overo boards due to a regression in
> >> 4.7. I bisected it down to
> >>
> >> 	d2d00862dfbb ("memory: omap-gpmc: Support general purpose input
> >> 	for WAITPINs")
> > ...
> > 
> >> Note that simply fixing the Overo NAND issue would fix the Overo
> >> networking regression, but by restoring the 4.6 gpmc-probe behaviour
> >> similar regressions on other OMAP systems are also avoided.
> > 
> > Roger, got a better fix in mind?
> > 
> 
> Nope. I'll take patch 1 in my omap-gpmc queue for v4.8.
> Thanks for the fixes Johan.

Now that 4.7 has been released, you may want to consider adding a stable
tag also for the first patch to avoid similar issues on other systems
when they get updated to 4.7-stable.

Thanks,
Johan

[PATCH 0/3] ARM: omap: fix 4.7 gpmc networking regression

[Roger Quadros]

On 03/08/16 11:01, Johan Hovold wrote:
> On Wed, Aug 03, 2016 at 10:46:24AM +0300, Roger Quadros wrote:
>> On 02/08/16 13:35, Tony Lindgren wrote:
>>> * Johan Hovold <johan@kernel.org> [160724 05:11]:
>>>> Networking is currently broken for Overo boards due to a regression in
>>>> 4.7. I bisected it down to
>>>>
>>>> 	d2d00862dfbb ("memory: omap-gpmc: Support general purpose input
>>>> 	for WAITPINs")
>>> ...
>>>
>>>> Note that simply fixing the Overo NAND issue would fix the Overo
>>>> networking regression, but by restoring the 4.6 gpmc-probe behaviour
>>>> similar regressions on other OMAP systems are also avoided.
>>>
>>> Roger, got a better fix in mind?
>>>
>>
>> Nope. I'll take patch 1 in my omap-gpmc queue for v4.8.
>> Thanks for the fixes Johan.
> 
> Now that 4.7 has been released, you may want to consider adding a stable
> tag also for the first patch to avoid similar issues on other systems
> when they get updated to 4.7-stable.
> 

Yes, that was my plan as well.

cheers,
-roger

[PATCH 0/3] ARM: omap: fix 4.7 gpmc networking regression

[Tony Lindgren]

* Roger Quadros <rogerq@ti.com> [160803 02:56]:
> On 03/08/16 11:01, Johan Hovold wrote:
> > On Wed, Aug 03, 2016 at 10:46:24AM +0300, Roger Quadros wrote:
> >> On 02/08/16 13:35, Tony Lindgren wrote:
> >>> * Johan Hovold <johan@kernel.org> [160724 05:11]:
> >>>> Networking is currently broken for Overo boards due to a regression in
> >>>> 4.7. I bisected it down to
> >>>>
> >>>> 	d2d00862dfbb ("memory: omap-gpmc: Support general purpose input
> >>>> 	for WAITPINs")
> >>> ...
> >>>
> >>>> Note that simply fixing the Overo NAND issue would fix the Overo
> >>>> networking regression, but by restoring the 4.6 gpmc-probe behaviour
> >>>> similar regressions on other OMAP systems are also avoided.
> >>>
> >>> Roger, got a better fix in mind?
> >>>
> >>
> >> Nope. I'll take patch 1 in my omap-gpmc queue for v4.8.
> >> Thanks for the fixes Johan.
> > 
> > Now that 4.7 has been released, you may want to consider adding a stable
> > tag also for the first patch to avoid similar issues on other systems
> > when they get updated to 4.7-stable.
> > 
> 
> Yes, that was my plan as well.

OK and I'm now finally applying the dts fixes into omap-for-v4.8/fixes.
Sorry for the delay.

Tony