[PATCH] gpiolib: return quietly from gpiod_get_direction() without .get_direction()

[PATCH] gpiolib: return quietly from gpiod_get_direction() without .get_direction()

[Mehmet Fide]

From: Mehmet Fide <mehmet.fide@screeningeagle.com>

Since commit 471e998c0e31 ("gpiolib: remove redundant callback check")
gpiod_get_direction() lets gpiochip_get_direction() WARN when the
controller does not implement .get_direction(). Callers of the public
API have no way to check for the callback themselves, so any of them
hitting such a controller now produces a backtrace.

One reachable case is the i2c generic GPIO bus recovery:
i2c_register_adapter() calls gpiod_get_direction() on the SDA line,
and on a Vybrid VF500 (gpio-vf610 has no .get_direction(), the pad
direction lives in the iomuxc, not in the GPIO block) every i2c
adapter probe logs

  WARNING: drivers/gpio/gpiolib.c:431 at gpiod_get_direction+0x16c/0x19c
  ...
  gpiod_get_direction from i2c_register_adapter+0x5bc/0x7f4
  i2c_register_adapter from i2c_imx_probe+0x3fc/0x6a0

Commit d761c7e38a00 ("gpiolib: Check gc->get_direction() before
calling gpiod_get_direction()") already shields the debugfs dump the
same way. Do it once inside gpiod_get_direction() instead, and return
-EOPNOTSUPP quietly, which restores the pre-471e998c0e31 behavior for
external callers.

Tested on a Colibri VF50: the boot log goes from 21 identical
backtraces to none, and the i2c recovery init degrades exactly as
before, by skipping set_sda.

Fixes: 471e998c0e31 ("gpiolib: remove redundant callback check")
Signed-off-by: Mehmet Fide <mehmet.fide@screeningeagle.com>
---
 drivers/gpio/gpiolib.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index c433a095907f..ad9740a3b42d 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -464,6 +464,14 @@ int gpiod_get_direction(struct gpio_desc *desc)
 	if (!guard.gc)
 		return -ENODEV;
 
+	/*
+	 * Callers of the public API cannot know whether the controller
+	 * implements .get_direction(), so bail out quietly instead of
+	 * letting gpiochip_get_direction() WARN on them.
+	 */
+	if (!guard.gc->get_direction)
+		return -EOPNOTSUPP;
+
 	offset = gpiod_hwgpio(desc);
 	flags = READ_ONCE(desc->flags);
 
-- 
2.54.0

Re: [PATCH] gpiolib: return quietly from gpiod_get_direction() without .get_direction()

[Mehmet Fide]

Hello,

A gentle ping on this one, sent a week ago and I have not seen a reply:

  https://lore.kernel.org/linux-gpio/20260813193715.2346477-1-mehmet.fide@gmail.com/

To recap: gpiod_get_direction() warns when a chip has no .get_direction(),
which is a legitimate thing for a chip to lack. On vf610 the direction is
not in the GPIO block at all, it is a bit of the pinmux pad register, so
the driver cannot implement the callback and every caller that asks for a
direction produces a WARN.

Happy to respin or take a different approach if you would rather solve it
elsewhere.

Best regards,
Mehmet Fide

Re: [PATCH] gpiolib: return quietly from gpiod_get_direction() without .get_direction()

[Bartosz Golaszewski]

On Thu, 20 Aug 2026 13:12:34 +0200, Mehmet Fide <mehmet.fide@gmail.com> said:
> Hello,
>
> A gentle ping on this one, sent a week ago and I have not seen a reply:
>

Yeah, this is August in Europe for you, I've been OoO and will be until the
end of this month.

>   https://lore.kernel.org/linux-gpio/20260813193715.2346477-1-mehmet.fide@gmail.com/
>
> To recap: gpiod_get_direction() warns when a chip has no .get_direction(),
> which is a legitimate thing for a chip to lack. On vf610 the direction is
> not in the GPIO block at all, it is a bit of the pinmux pad register, so
> the driver cannot implement the callback and every caller that asks for a
> direction produces a WARN.
>
> Happy to respin or take a different approach if you would rather solve it
> elsewhere.

I would rather implement the missing callback in gpio-mmio. We already call
into pinctrl if needed when setting direction, could we call
pinctrl_gpio_get_config() here and read the direction from the underlying
pinctrl driver?

Thanks,
Bartosz