| Message ID | 1417529705-1515-1-git-send-email-acourbot@nvidia.com |
|---|---|
| State | Accepted |
| Headers | show |
Hi Alexander, On Tue, Dec 2, 2014 at 3:15 PM, Alexandre Courbot <acourbot@nvidia.com> wrote: > Commit 14e85c0e69d5 ("gpio: remove gpio_descs global array") changed > gpio_to_desc()'s behavior to return NULL not only for GPIOs numbers > not in the valid range, but also for all GPIOs whose controller has not > been probed yet. Although this behavior is more correct (nothing hints > that these GPIO numbers will be populated later), this affects > gpio_request() and gpio_request_one() which call gpiod_request() with a > NULL descriptor, causing it to return -EINVAL instead of the expected > -EPROBE_DEFER for a non-probed GPIO. > > gpiod_request() is only called with a descriptor obtained from > gpio_to_desc() from these two functions, so address the issue there. > > Other ways to obtain GPIOs rely on well-defined mappings and can thus > return -EPROBE_DEFER only for relevant GPIOs, and are thus not affected > by this issue. > > Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> > Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> > --- > v2: > - Add Geert's Tested-by > - Only display scary warning on gpio_to_desc() is the GPIO is outside > the valid range (pre gpio_desc array removal behavior) Thanks, the scary warnings are gone, together with a few superfluous "gpio-0 (?): gpiod_request: status -517" messages. Have a good night! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Dec 2, 2014 at 3:15 PM, Alexandre Courbot <acourbot@nvidia.com> wrote: > Commit 14e85c0e69d5 ("gpio: remove gpio_descs global array") changed > gpio_to_desc()'s behavior to return NULL not only for GPIOs numbers > not in the valid range, but also for all GPIOs whose controller has not > been probed yet. Although this behavior is more correct (nothing hints > that these GPIO numbers will be populated later), this affects > gpio_request() and gpio_request_one() which call gpiod_request() with a > NULL descriptor, causing it to return -EINVAL instead of the expected > -EPROBE_DEFER for a non-probed GPIO. > > gpiod_request() is only called with a descriptor obtained from > gpio_to_desc() from these two functions, so address the issue there. > > Other ways to obtain GPIOs rely on well-defined mappings and can thus > return -EPROBE_DEFER only for relevant GPIOs, and are thus not affected > by this issue. > > Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> > Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> > --- > v2: OK threw out v1 and applied this instead. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/gpio/gpiolib-legacy.c b/drivers/gpio/gpiolib-legacy.c index 078ae6c..8b83099 100644 --- a/drivers/gpio/gpiolib-legacy.c +++ b/drivers/gpio/gpiolib-legacy.c @@ -24,6 +24,10 @@ int gpio_request_one(unsigned gpio, unsigned long flags, const char *label) desc = gpio_to_desc(gpio); + /* Compatibility: assume unavailable "valid" GPIOs will appear later */ + if (!desc && gpio_is_valid(gpio)) + return -EPROBE_DEFER; + err = gpiod_request(desc, label); if (err) return err; @@ -62,7 +66,13 @@ EXPORT_SYMBOL_GPL(gpio_request_one); int gpio_request(unsigned gpio, const char *label) { - return gpiod_request(gpio_to_desc(gpio), label); + struct gpio_desc *desc = gpio_to_desc(gpio); + + /* Compatibility: assume unavailable "valid" GPIOs will appear later */ + if (!desc && gpio_is_valid(gpio)) + return -EPROBE_DEFER; + + return gpiod_request(desc, label); } EXPORT_SYMBOL_GPL(gpio_request); diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index 0b271ef8..56b7c5d 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -77,7 +77,9 @@ struct gpio_desc *gpio_to_desc(unsigned gpio) spin_unlock_irqrestore(&gpio_lock, flags); - WARN(1, "invalid GPIO %d\n", gpio); + if (!gpio_is_valid(gpio)) + WARN(1, "invalid GPIO %d\n", gpio); + return NULL; } EXPORT_SYMBOL_GPL(gpio_to_desc);
Commit 14e85c0e69d5 ("gpio: remove gpio_descs global array") changed gpio_to_desc()'s behavior to return NULL not only for GPIOs numbers not in the valid range, but also for all GPIOs whose controller has not been probed yet. Although this behavior is more correct (nothing hints that these GPIO numbers will be populated later), this affects gpio_request() and gpio_request_one() which call gpiod_request() with a NULL descriptor, causing it to return -EINVAL instead of the expected -EPROBE_DEFER for a non-probed GPIO. gpiod_request() is only called with a descriptor obtained from gpio_to_desc() from these two functions, so address the issue there. Other ways to obtain GPIOs rely on well-defined mappings and can thus return -EPROBE_DEFER only for relevant GPIOs, and are thus not affected by this issue. Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> --- v2: - Add Geert's Tested-by - Only display scary warning on gpio_to_desc() is the GPIO is outside the valid range (pre gpio_desc array removal behavior) drivers/gpio/gpiolib-legacy.c | 12 +++++++++++- drivers/gpio/gpiolib.c | 4 +++- 2 files changed, 14 insertions(+), 2 deletions(-)