On Mon, Jul 30, 2012 at 8:57 AM, NeilBrown <ne...@suse.de> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
