[PATCH v2 0/2] gpio: mmio: report the line direction on chips without direction registers
Mehmet Fide
mehmet.fide at gmail.com
Wed Sep 2 00:39:44 PDT 2026
From: Mehmet Fide <mehmet.fide at screeningeagle.com>
Hi Bartosz, Linus,
this replaces the gpiolib guard patch [1], along the lines Bartosz
suggested there: instead of teaching gpiod_get_direction() to stay quiet
when a chip has no get_direction(), give gpio-mmio one and let the pin
controller tell it what the pad does.
The user is the Vybrid GPIO block (gpio-vf610, a generic mmio chip with
GPIO_GENERIC_PINCTRL_BACKEND and no direction registers, the direction
lives in the iomuxc pad as the OBE bit). Today every
gpiod_get_direction() there trips the WARN in gpiolib, 21 backtraces per
boot on a Colibri VF61/VF50.
Patch 1 is the pinctrl-imx side. Bartosz asked whether the raw register
coming back from pin_config_get() is a bug in pinctrl-imx: it is, the
callback never looked at which parameter was requested. It now answers
PIN_CONFIG_OUTPUT_ENABLE and PIN_CONFIG_INPUT_ENABLE on SoCs that say
where those bits live (Vybrid: OBE bit 1, IBE bit 0) and -ENOTSUPP for
everything else; the debugfs dump, the only raw-register user, reads the
register through its own helper. Converting the driver fully to generic
pinconf is a bigger job than this fix needs.
Patch 2 keeps the direction in gpio-mmio's existing shadow and installs
the shadow-reading get_direction() for the "pinctrl backend, no
direction registers" combination. The pad is asked once, from request(),
in process context. v1 asked pinctrl from get_direction() itself; the
Sashiko review pointed out that gpiochip_lock_as_irq() calls
get_direction() for !can_sleep chips under the irq descriptor lock, so
the pinctrl mutex is not an option there.
Tested on a Colibri VF61 (Iris carrier) on top of gpio/for-next, with
DEBUG_ATOMIC_SLEEP and PROVE_LOCKING enabled this time: no backtraces,
and /sys/kernel/debug/gpio shows the right direction for every requested
line (the hogs, the SD card detect input, the USB VBUS regulator
output). Lines the pin controller cannot answer for keep
the input default gpiolib assumed before, so nothing that worked before
is affected. The initial direction scan in gpiochip_add_data_with_key()
runs before the pin ranges exist and still guesses; only requested lines
get the real answer.
Patch 2 needs patch 1 to give correct answers; taking both through one
tree, with an ack from the other side, avoids the window.
[1] https://lore.kernel.org/linux-gpio/20260813193715.2346477-1-mehmet.fide@gmail.com/
Mehmet Fide (2):
pinctrl: imx: answer OUTPUT_ENABLE/INPUT_ENABLE queries from the pad
register
gpio: mmio: track the direction of chips without direction registers
drivers/gpio/gpio-mmio.c | 63 +++++++++++++++++++++--
drivers/pinctrl/freescale/pinctrl-imx.c | 51 ++++++++++++++++--
drivers/pinctrl/freescale/pinctrl-imx.h | 4 ++
drivers/pinctrl/freescale/pinctrl-vf610.c | 2 +
4 files changed, 113 insertions(+), 7 deletions(-)
--
2.54.0
More information about the linux-arm-kernel
mailing list