Commit 14e85c0e69 ("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>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpio_ensure_requested() has been introduced in Feb. 2008 by commit
d2876d08d8 to force users of the GPIO API to explicitly request GPIOs
before using them.
Hopefully by now all GPIOs are correctly requested and this extra check
can be omitted ; in any case the GPIO maintainers won't feel bad if
machines start failing after 6 years of warnings.
This patch removes that function from the dark ages.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpio_ensure_requested() only makes sense when using the integer-based
GPIO API, so make sure it is called from there instead of the gpiod
API which we know cannot be called with a non-requested GPIO anyway.
The uses of gpio_ensure_requested() in the gpiod API were kind of
out-of-place anyway, so putting them in gpio-legacy.c helps clearing the
code.
Actually, considering the time this ensure_requested mechanism has been
around, maybe we should just turn this patch into "remove
gpio_ensure_requested()" if we know for sure that no user depend on it
anymore?
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpio_lock/unlock_as_irq() are working with (chip, offset) arguments and
are thus not using the old integer namespace. Therefore, there is no
reason to have gpiod variants of these functions working with
descriptors, especially since the (chip, offset) tuple is more suitable
to the users of these functions (GPIO drivers, whereas GPIO descriptors
are targeted at GPIO consumers).
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The gpio include file and the gpio documentation declare and document
GPIOF_ACTIVE_LOW as one of the flags to be passed to gpio_request_one
and related functions. However, the flag is not evaluated or used.
This can cause problems in at least two areas: First, the same API can
be used to auto-export pins to user space. The missing support for
GPIOF_ACTIVE_LOW results in unexpected behavior for such auto-exported
pins. Second, the requested gpio pin can be convered for use by
gpiod functions with gpio_to_desc(). While gpio API functions do not
support GPIOF_ACTIVE_LOW, gpiod functions do, which again results in
unexpected behavior.
Check the flag in gpio_request_one and set the gpio internal flag
FLAG_ACTIVE_LOW if it is set to address those problems.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The old integer GPIO interface is, in effect, a privileged user of the
gpiod interface. Reflect this fact further by moving legacy GPIO support
into its own source file. This makes the code clearer and will allow us
to disable legacy GPIO support in the (far) future.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Alexandre Courbot