[PATCH RFC 4/7] [GPIO] Let drivers link if they support GPIO API as an addition

[Anton Vorontsov]

On Mon, Dec 10, 2007 at 02:55:24PM -0800, David Brownell wrote:
> > I'm interested in your opinion about that patch. You're also Cc'ed
> > to patch that using that feature.
> >
> > I know, currently that patch will conflict with GPIOLIB patches in -mm,
> > so this is only RFC.
> 
> The point of CONFIG_GENERIC_GPIO is to be *the* conditional used to
> tell whether that programming interface is available ... starting
> from "#include <asm/gpio.h>", and including all gpio_*() calls.
> 
> So my first reaction is to not like this patch.  It changes semantics
> in an incompatible way.  And AFAICT, needlessly so.

Why incompatible? gpio-aware drivers will get -ENOSYS on gpio_request,
thus they will not do anything wrong. GPIO-only drivers could still
depend on GENERIC_GPIO, and their behaviour will not change.

> What other options did consider?  Like, why not #ifdef the GPIO parts
> of that NAND driver,

Hehe, it's used to avoid #ifdef hell indeed. ;-) And no-op wrappers
like that I purposed is widely used to avoid #ifdefs. They will just
optimize away.

> or have the whole driver depend on GENERIC_GPIO?

Well, this is an option, and I was considering this. Further more,
I implemented gpio api for all platforms which currently using fsl
upm nand, so in theory I can add "depends on GENERIC_GPIO".

But the thing is: some drivers don't actually *require* gpios, they
can use it, but at the same time they might live without it.

As for fsl upm nand (the user of that change), it can poll status
from the nand chip instead of looking for RNB gpio. So, strict
depending on GENERIC_GPIO looks weird in that case.


Thanks,

-- 
Anton Vorontsov
email: cbou at mail.ru
backup email: ya-cbou at yandex.ru
irc://irc.freenode.net/bd2