[PATCH] arm: ixp4xx, u300: Select ARCH_REQUIRE_GPIOLIB, not GENERIC_GPIO

Russell King - ARM Linux [off-list ref] writes:

Hi,

On Mon, Sep 05, 2011 at 08:54:30AM +0200, Arnaud Patard wrote:

quoted

The problem here is that gpio_request_one has been added to the ads7846
driver but gpio_request_one is not defined in GENERIC_GPIO case (I
guess that other (arm and non-arm) platforms may hit similar troubles
with gpio_request_one. One quick fix would be to add a gpio_request_one
function say in asm-generic/gpio.h. One other fix would be to define
gpio_request_one and gpio_request_array in each
machine/platform/... specific header. Don't know what's the best
solution.

It looks like gpio_request_one() and gpio_request_array() have been added
at the wrong level in the GPIO support code.

There's two levels to the GPIO support code:

1. GENERIC_GPIO - for platforms which use the gpio_* interfaces.
2. GPIOLIB - for platforms which want the gpio library for handling multiple
   GPIO controllers.

There is nothing GPIOLIB specific to the gpio_request_*() interfaces, so
to put them in gpiolib.c and include/asm-generic/gpio.h seems rather silly.

On the other hand, for the single ARM kernel project, we do need everyone
to move to GPIOLIB so that the GPIO calls can be bound appropriately at
runtime - which means this problem goes away.  So probably the right
solution is for IXP4xx etc to move over completely to gpiolib.

I thought about it but I considered it was too late to do that. I don't
think that moving to gpiolib u300/ixp4xx in -rc is a good idea. imho
doing it for next kernel is better but this won't solve the build
failure. Of course, you can tell me I'm plain wrong and I'll look at
converting them to gpiolib asap. Then we'll need some testers as I don't
have neither u300 nor ixp4xx systems.

Also, moving u300/ixp4xx to gpiolib will solve the issue for ARM but I
fear that other architectures may be affected by similar trouble.

Arnaud