drivers/gpio/gpiolib.c | 8 ++++++++ 1 file changed, 8 insertions(+)
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
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
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
© 2016 - 2026 Red Hat, Inc.