kernel/git/next/linux-next.git/drivers/gpio/gpio-shared-proxy.c, branch stable

gpio: shared: make the voting mechanism adaptable

2026-07-06T13:26:17+00:00

The current voting mechanism in GPIO shared proxy assumes that "low" is always the default value and users can only vote for driving the GPIO "high" in which case it will remain high as long as there's at least one user voting. This makes it impossible to use the automatic sharing management for certain use-cases such as the write-protect GPIOs of EEPROMs which are requested "high" and driven "low" to enable writing. In this case, if the WP GPIO is shared by multiple EEPROMs, and at least one of them wants to enable writing, the pin must be set to "low". Modify the voting heuristic to assume the value set by the first user on request to be the "default" and subseqent calls to gpiod_set_value() will constitute votes for a change of the value to the opposite. In the wp-gpios case it will mean that the nvmem core requests the GPIO as "out-high" for all EEPROMs sharing the pin, and when one of them wants to write, the pin will be driven low, enabling it. Fixes: e992d54c6f97 ("gpio: shared-proxy: implement the shared GPIO proxy driver") Reported-by: Marek Vasut Closes: https://lore.kernel.org/all/20260511163518.51104-1-marex@nabladev.com/ Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260630-gpio-shared-dynamic-voting-v3-1-8ecf0542953b@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski

Merge tag 'gpio-fixes-for-v7.2-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux

2026-07-03T15:38:12+00:00

Pull gpio fixes from Bartosz Golaszewski: - check the return value of gpiochip_add_data() in gpio-mvebu and gpio-htc-egpio - avoid locking context issues with GPIO drivers using the shared GPIO proxy by only allowing sleeping operations (atomic GPIO ops don't really make sense in shared context anyway) - with the above: restore non-sleeping GPIO access in pinctrl-meson - fix return value on OOM in gpio-timberdale - fix interrupt handling in gpio-mt7621 - support both A and B variants of NCT6126D in gpio-f7188x * tag 'gpio-fixes-for-v7.2-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: pinctrl: meson: restore non-sleeping GPIO access gpio: timberdale: Return -ENOMEM on dynamic memory allocation in probe gpio: mt7621: be sure IRQ domain is created before exposing GPIO chips gpio: mt7621: more robust management of IRQ domain teardown gpio: mt7621: avoid corruption of shared interrupt trigger state gpio: shared-proxy: always serialize with a sleeping mutex gpio-f7188x: Add support for NCT6126D version B gpio: htc-egpio: use managed gpiochip registration gpio: mvebu: fail probe if gpiochip registration fails

Replace by more specific (c files)

2026-07-03T05:38:17+00:00

Replace the #include of by the more specific where applicable. For most cases the include can be dropped completely, only a few drivers need one or two headers added. Acked-by: Danilo Krummrich Acked-by: Takashi Sakamoto Acked-by: Bjorn Helgaas Link: https://patch.msgid.link/1a3f2007c5c5dcf555c09a4035ce3ae8ef1b6c49.1782808461.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König (The Capable Hub)

gpio: shared-proxy: always serialize with a sleeping mutex

2026-06-30T14:01:28+00:00

The shared GPIO descriptor used either a mutex or a spinlock, chosen at runtime from the underlying chip's can_sleep: shared_desc->can_sleep = gpiod_cansleep(shared_desc->desc); ... if (can_sleep) mutex_lock(); else spin_lock_irqsave(); can_sleep describes only the value path (->get/->set). Under the same lock, however, the proxy may call gpiod_set_config() and gpiod_direction_*(), which can reach pinctrl paths that take a mutex (e.g. gpiod_set_config() -> gpiochip_generic_config() -> pinctrl_gpio_set_config()), independent of can_sleep. On a controller with non-sleeping MMIO value ops the descriptor lock was a spinlock, so the sleeping pinctrl call ran from atomic context. Reproduced on an Amlogic A113X board with the workaround from commit 28f240683871 ("pinctrl: meson: mark the GPIO controller as sleeping") reverted; the original Khadas VIM3 report hit the same path: BUG: sleeping function called from invalid context __mutex_lock pinctrl_get_device_gpio_range pinctrl_gpio_set_config gpiochip_generic_config gpiod_set_config gpio_shared_proxy_set_config <- voting spinlock held ... mmc_pwrseq_simple_probe The spinlock existed to take the value vote from atomic context, but the vote and the (possibly sleeping) control operations share the same state and lock, so this scheme cannot serialize config under a mutex and still offer atomic value access. Always serialize the shared descriptor with a mutex instead and mark the proxy a sleeping gpiochip, driving the underlying GPIO through the cansleep value accessors: those are valid for both sleeping and non-sleeping chips, so value access keeps working on fast controllers, at the cost of no longer being atomic. With every vote edge now driven through the cansleep value setter, gpio_shared_proxy_set_unlocked() no longer needs a per-call setter: drop its set_func callback and call gpiod_set_value_cansleep() directly. The shared direction_output path reaches it only once the line is already an output, so driving the value there is equivalent to re-issuing gpiod_direction_output(), without the redundant per-edge re-assertion of drive config and bias. This is observable: consumers gating on gpiod_cansleep() take their sleeping branch on a proxied GPIO (mmc-pwrseq-emmc skips its emergency-restart reset handler; its normal reset is unaffected), and consumers that reject sleeping GPIOs (pwm-gpio, ps2-gpio, ...) would fail to probe. Such atomic users do not share a pin through the proxy, whose purpose is voting on shared reset/enable lines. The same narrowing already applies on Amlogic since that workaround, and rockchip addressed the identical splat per-driver in commit 7ca497be0016 ("gpio: rockchip: Stop calling pinctrl for set_direction"); fixing the proxy addresses the locking error once, for every controller. The lock type was added by commit a060b8c511ab ("gpiolib: implement low-level, shared GPIO support"); the sleeping call under it arrived with the proxy driver. Fixes: e992d54c6f97 ("gpio: shared-proxy: implement the shared GPIO proxy driver") Reported-by: Marek Szyprowski Closes: https://lore.kernel.org/all/00107523-7737-4b92-a785-14ce4e93b8cb@samsung.com/ Signed-off-by: Viacheslav Bocharov Link: https://patch.msgid.link/20260630101545.800625-2-v@baodeep.com Signed-off-by: Bartosz Golaszewski

gpio: shared: undo the vote of the proxy on GPIO free

2026-05-28T13:23:39+00:00

When the user of a shared GPIO managed by gpio-shared-proxy calls gpiod_put() to release it, we never undo the potential "vote" for driving the shared line "high". In the free() callback, check if this proxy voted for "high" and - if so - decrease the number of votes and potentially revert the value to low if this is the last user. Cc: stable@vger.kernel.org Fixes: e992d54c6f97 ("gpio: shared-proxy: implement the shared GPIO proxy driver") Closes: https://sashiko.dev/#/patchset/20260513-gpio-shared-dynamic-voting-v1-1-8e1c49961b7d%40oss.qualcomm.com Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260522-gpio-shared-free-vote-v3-1-8a4fddc6bedb@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski

gpio: shared-proxy: set suppress_bind_attrs

2025-11-28T08:29:31+00:00

User-space must not fiddle with shared-proxy auxiliary devices. Disable bind/unbind attributes in sysfs. Link: https://lore.kernel.org/r/20251126191730.66277-1-brgl@bgdev.pl Signed-off-by: Bartosz Golaszewski

gpio: shared-proxy: implement the shared GPIO proxy driver

2025-11-17T09:16:51+00:00

Add a virtual GPIO proxy driver which arbitrates access to a single shared GPIO by multiple users. It works together with the core shared GPIO support from GPIOLIB and functions by acquiring a reference to a shared GPIO descriptor exposed by gpiolib-shared and making sure that the state of the GPIO stays consistent. In general: if there's only one user at the moment: allow it to do anything as if this was a normal GPIO (in essence: just propagate calls to the underlying real hardware driver). If there are more users: don't allow to change the direction set by the initial user, allow to change configuration options but warn about possible conflicts and finally: treat the output-high value as a reference counted, logical "GPIO enabled" setting, meaning: the GPIO value is set to high when the first user requests it to be high and back to low once the last user stops "voting" for high. Reviewed-by: Linus Walleij Acked-by: Linus Walleij Link: https://lore.kernel.org/r/20251112-gpio-shared-v4-4-b51f97b1abd8@linaro.org Signed-off-by: Bartosz Golaszewski