Re: [GIT PULL] GPIO changes for v3.6

[Linus Walleij]

On Mon, Jul 30, 2012 at 8:57 AM, NeilBrown <neilb@xxxxxxx> wrote:

> it means that if !gpio_is_valid(gpio), the error returned is EPROBE_DEFER
> which isn't right (an invalid gpio number will never become valid).
> If a driver happened to use gpio_request to check the validity of the gpio
> rather than doing it itself, it would defer the probe, rather than assume
> that the GPIO doesn't exist.
>
> I would suggest the following.  Reasonable?

Unless there is a firm regression solved by this we can very well
discuss this until the next merge window.

The solution from Mark looks very much like the method used in
regulators, clocks etc. I bet if we look at the error paths of the
driver doing gpio_is_valid() the majority will be something in the
probe() path just bailing out if that was not supplied, alternatively
shunting in some non-GPIO code.

The more typical problem for
deferring driver to solve will be something like commit
2805b9ab7c836cfbe01e86129983e36205078cb2
where we have to check for -EPROBE_DEFER explicitly
and bail out before doing any gpio_is_valid() checks.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/