ARM: orion5x: Fix GPIO enable bits for MPP9

PATCH Superseded Ben Hutchings 3 participants 4 messages Apr 7, 2012 – Apr 11, 2012

Subsystems (3)

Arm (32-bit) Arm sub-architectures Arm/Marvell Dove/MV78xx0/Orion SoC support

lore

Share & tools

lore

Ben Hutchings

author

2012-04-07 04:08 UTC #0 lore raw

PATCH 1/1 ARM: orion5x: Fix GPIO enable bits for MPP9

Commit 554cdaefd1cf7bb54b209c4e68c7cec87ce442a9 seems to have accidentally inverted the GPIO valid bits for MPP9 (only). For the mv2120 platform which uses MPP9 as a GPIO LED device, this results in the error:

[   12.711476] leds-gpio: probe of leds-gpio failed with error -22

Reported-by Henry von Tresckow <[email protected]>

References: http://bugs.debian.org/667446

Signed-off-by Ben Hutchings <[email protected]>

Cc stable at vger.kernel.org [v3.0+]

---
I know nothing about this platform, and this is totally untested. But it does look quite straightforward...

Ben.

 arch/arm/mach-orion5x/mpp.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

arch/arm/mach-orion5x/mpp.h +2 -2

index eac6897..db70e79 100644
@@ -65,8 +65,8 @@
 #define MPP8_GIGE               MPP(8,  0x1, 0, 0, 1,   1,   1)
 
 #define MPP9_UNUSED		MPP(9,  0x0, 0, 0, 1,   1,   1)
-#define MPP9_GPIO		MPP(9,  0x0, 0, 0, 1,   1,   1)
-#define MPP9_GIGE               MPP(9,  0x1, 1, 1, 1,   1,   1)
+#define MPP9_GPIO		MPP(9,  0x0, 1, 1, 1,   1,   1)
+#define MPP9_GIGE               MPP(9,  0x1, 0, 0, 1,   1,   1)
 
 #define MPP10_UNUSED		MPP(10, 0x0, 0, 0, 1,   1,   1)
 #define MPP10_GPIO		MPP(10, 0x0, 1, 1, 1,   1,   1)

Signature · 1 line

1.7.9.5

Sergei Shtylyov

2012-04-07 17:46 UTC #1 lore raw

PATCH 1/1 ARM: orion5x: Fix GPIO enable bits for MPP9

Hello.

Quoted 1 line · Ben Hutchings

Commit 554cdaefd1cf7bb54b209c4e68c7cec87ce442a9 seems to have

Please also specify that commit's summary in parens.

Quoted 10 lines

accidentally inverted the GPIO valid bits for MPP9 (only). For the mv2120 platform which uses MPP9 as a GPIO LED device, this results in the error:
[   12.711476] leds-gpio: probe of leds-gpio failed with error -22
Reported-by Henry von Tresckow<[email protected]>
References: http://bugs.debian.org/667446
Signed-off-by Ben Hutchings<[email protected]>
Cc stable at vger.kernel.org [v3.0+]

WBR, Sergei

Jason Cooper

2012-04-11 01:21 UTC #2 lore raw

PATCH 1/1 ARM: orion5x: Fix GPIO enable bits for MPP9

In reply to Ben Hutchings

Quoted 7 lines · Ben Hutchings

Commit 554cdaefd1cf7bb54b209c4e68c7cec87ce442a9 seems to have accidentally inverted the GPIO valid bits for MPP9 (only). For the mv2120 platform which uses MPP9 as a GPIO LED device, this results in the error:
[   12.711476] leds-gpio: probe of leds-gpio failed with error -22

Quoted 7 lines

Reported-by Henry von Tresckow <[email protected]>
References: http://bugs.debian.org/667446
Signed-off-by Ben Hutchings <[email protected]>
Cc stable at vger.kernel.org [v3.0+]
---
I know nothing about this platform, and this is totally untested. But it does look quite straightforward...

Can we confirm that it doesn't break functionality on the following:

* d2net            (MPP9_GPIO, /* Rear power switch (auto|off) */)
* db88f5281        (MPP9_GPIO, /* JP3, CON11.3 */)
* dns-323          (MPP9_GPIO, /* power button switch */)
* dns-323b         (MPP9_GPIO, /* power button switch */)
* dns-323c         (MPP9_GPIO, /* i/o left amber LED */)
* ls-chl           (MPP9_GPIO, /* USB POWER */)
* ls_hgl           (MPP9_GPIO, /* USB_PWR */)
* lsmini           (MPP9_GPIO, /* LED_FUNC */)
* mv2120           (MPP9_GPIO, /* SATA 1 fail LED */)
* net2big          (MPP9_GPIO, /* Rear power switch (auto|off) */)
* rd88f5181l-fxo   (MPP9_GPIO, /* GE_RXERR */)
* rd88f5181l-ge    (MPP9_GPIO, /* GE_RXERR */)

* terastation_pro2 (MPP9_GPIO, /* RTC int */)
* wnr854t (MPP9_GIGE, /* GE_RXERR */)
* wrt350n-v2 (MPP9_GIGE, /* GE_RXERR */)

Also, while I'm looking at it, Is it correct that four boards (rd88f5181l-*, wnr854t, wrt350n-v2) use the same pin for the same purpose, two declare it as GPIO, and two as GIGE... :-/ Perhaps part of the same problem?

thx,

Jason.

Quoted 30 lines

Ben.

 arch/arm/mach-orion5x/mpp.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

arch/arm/mach-orion5x/mpp.h +2 -2

index eac6897..db70e79 100644
@@ -65,8 +65,8 @@
 #define MPP8_GIGE               MPP(8,  0x1, 0, 0, 1,   1,   1)
 
 #define MPP9_UNUSED		MPP(9,  0x0, 0, 0, 1,   1,   1)
-#define MPP9_GPIO		MPP(9,  0x0, 0, 0, 1,   1,   1)
-#define MPP9_GIGE               MPP(9,  0x1, 1, 1, 1,   1,   1)
+#define MPP9_GPIO		MPP(9,  0x0, 1, 1, 1,   1,   1)
+#define MPP9_GIGE               MPP(9,  0x1, 0, 0, 1,   1,   1)
 
 #define MPP10_UNUSED		MPP(10, 0x0, 0, 0, 1,   1,   1)
 #define MPP10_GPIO		MPP(10, 0x0, 1, 1, 1,   1,   1)

Signature · 8 lines

1.7.9.5



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Ben Hutchings

author

2012-04-11 01:38 UTC #3 lore raw

PATCH 1/1 ARM: orion5x: Fix GPIO enable bits for MPP9

Quoted 30 lines · Jason Cooper

Quoted 7 lines · Ben Hutchings
Commit 554cdaefd1cf7bb54b209c4e68c7cec87ce442a9 seems to have accidentally inverted the GPIO valid bits for MPP9 (only). For the mv2120 platform which uses MPP9 as a GPIO LED device, this results in the error:
[   12.711476] leds-gpio: probe of leds-gpio failed with error -22
Quoted 7 lines
Reported-by Henry von Tresckow <[email protected]>
References: http://bugs.debian.org/667446
Signed-off-by Ben Hutchings <[email protected]>
Cc stable at vger.kernel.org [v3.0+]
---
I know nothing about this platform, and this is totally untested. But it does look quite straightforward...
Can we confirm that it doesn't break functionality on the following:
* d2net            (MPP9_GPIO, /* Rear power switch (auto|off) */)
* db88f5281        (MPP9_GPIO, /* JP3, CON11.3 */)
* dns-323          (MPP9_GPIO, /* power button switch */)
* dns-323b         (MPP9_GPIO, /* power button switch */)
* dns-323c         (MPP9_GPIO, /* i/o left amber LED */)
* ls-chl           (MPP9_GPIO, /* USB POWER */)
* ls_hgl           (MPP9_GPIO, /* USB_PWR */)
* lsmini           (MPP9_GPIO, /* LED_FUNC */)
* mv2120           (MPP9_GPIO, /* SATA 1 fail LED */)
* net2big          (MPP9_GPIO, /* Rear power switch (auto|off) */)
* rd88f5181l-fxo   (MPP9_GPIO, /* GE_RXERR */)
* rd88f5181l-ge    (MPP9_GPIO, /* GE_RXERR */)

Quoted 3 lines

* terastation_pro2 (MPP9_GPIO, /* RTC int */)
* wnr854t (MPP9_GIGE, /* GE_RXERR */)
* wrt350n-v2 (MPP9_GIGE, /* GE_RXERR */)

The flags in question control whether the pin is exposed to the rest of the system as a GPIO, not how the hardware is configured. Just look at how these tables and flags are being used in arch/arm/plat-orion/mpp.c:orion_mpp_conf(), and compare with all the other MPPn_GPIO definitions.

Also look at the old determine_type_encoding() function removed by the earlier commit: there is nothing special about MPP9.

mv2120 currently has broken LEDs because MPP9 is not exposed as a GPIO, and many of the others probably have the same problem.

Quoted 4 lines

Also, while I'm looking at it, Is it correct that four boards (rd88f5181l-*, wnr854t, wrt350n-v2) use the same pin for the same purpose, two declare it as GPIO, and two as GIGE... :-/ Perhaps part of the same problem?

I would guess that all those boards should specify MPP9_GIGE, but I'm just trying to fix a recent regression.

Ben.

Signature · 9 lines

Ben Hutchings
It is easier to change the specification to fit the program than vice versa.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120411/9a96ad1f/attachment-0001.sig>