Correct bad gpio naming

One of the GPIO names in drivers/gpio/gpio-lpc32xx.c was bad. Renaming gpi000 -> gpio00

index 5b69480..ddfacc5 100644
@@ -96,7 +96,7 @@ static const char *gpio_p2_names[LPC32XX_GPIO_P2_MAX] = {
 };
  static const char *gpio_p3_names[LPC32XX_GPIO_P3_MAX] = {
-	"gpi000", "gpio01", "gpio02", "gpio03",
+	"gpio00", "gpio01", "gpio02", "gpio03",
 	"gpio04", "gpio05"
 };

Applied. Careful though, this patch was corrupt (missing carriage return before 'static' and had to be applied by hand.

g.

Since you are modifying LPC32xx :) Which kernel version do you run? I was trying to get a board up with 3.0 (not booting) and 3.3-rc1 (build breakage). I even thought about removing that mach, since vital parts seem to be missing (Net, NAND) or broken. So, I am interested if there are still users.

CCing Kevin Wells, too: Any plans from NXP?

Thanks,

Wolfram

Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120124/01f81aa4/attachment.sig>

Hi,

I'm actively maintaining an LPC32xx machine line (WORK Microwave GmbH devices) at http://git.antcom.de/ - feel free to merge from there.

For me, it works fine with Linux 3.2.0.

The repo includes some additional features like NAND (esp. MLC controller, while NXP implemented an SLC driver), High Speed UARTs and ADC. Some of those are not yet integrated mainline, but I'm willing to help here. Looks like I will maintain it anyway for the next few years.

Expect the first one of the drivers to be submitted soon, I will do them one by one.

Thanks for keeping LPC32xx :-)

Roland

Cool, best answer I could get \o/

I think the first step should be adding a generic defconfig and make sure this builds and boots (I think I have a phy3250 somewhere, so I could test). After that new drivers would make sense. IIRC clock.c was pretty broken, we needed hacks to get USB working with a 2.6.35. I also see that your tree modifies it.

Kevin: Are you with us?

Regards,

Wolfram

Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120124/6d8e020a/attachment.sig>

I see that you are already at it ;-) - for the others: On the server "git.antcom.de", I meant repository "linux-2.6.git", branch "work92105".

Unfortunately, I currently don't have a phy3250, but can check tomorrow with colleagues.

I guess the work92105_defconfig is only useful once the drivers currently missing in mainline are merged. Or is there an arm specific tree I should update from?

Thanks in advance!

Roland

Shouldn't matter that much, or? Once the core support is back and works for your board, others could test with their boards.

You can keep the work92105_defconfig in your tree, but we'd need to introduce a lpc32xx_defconfig. That should start with a minimal (but working) config and can be extended once the drivers are in place.

Regards,

Wolfram

Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120124/17c3e0f3/attachment.sig>