From: Mehmet Fide <mehmet.fide@gmail.com>
To: Bartosz Golaszewski <brgl@kernel.org>, Linus Walleij <linusw@kernel.org>
Cc: Christophe Leroy <chleroy@kernel.org>,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
Mehmet Fide <mehmet.fide@screeningeagle.com>
Subject: [PATCH] gpiolib: return quietly from gpiod_get_direction() without .get_direction()
Date: Thu, 13 Aug 2026 21:37:15 +0200 [thread overview]
Message-ID: <20260813193715.2346477-1-mehmet.fide@gmail.com> (raw)
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
next reply other threads:[~2026-08-13 19:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-13 19:37 Mehmet Fide [this message]
2026-08-20 11:12 ` Mehmet Fide
2026-08-26 15:06 ` Bartosz Golaszewski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260813193715.2346477-1-mehmet.fide@gmail.com \
--to=mehmet.fide@gmail.com \
--cc=brgl@kernel.org \
--cc=chleroy@kernel.org \
--cc=linusw@kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mehmet.fide@screeningeagle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®