From: Viacheslav Bocharov <v@baodeep.com>
To: Linus Walleij <linusw@kernel.org>, Bartosz Golaszewski <brgl@kernel.org>
Cc: Neil Armstrong <neil.armstrong@linaro.org>,
Kevin Hilman <khilman@baylibre.com>,
Jerome Brunet <jbrunet@baylibre.com>,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Robin Murphy <robin.murphy@arm.com>,
Diederik de Haas <diederik@cknow-tech.com>,
linux-gpio@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-amlogic@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: [PATCH v3 0/2] gpio: fix sleeping-in-atomic in shared-proxy; restore meson non-sleeping
Date: Tue, 30 Jun 2026 13:15:43 +0300 [thread overview]
Message-ID: <20260630101545.800625-1-v@baodeep.com> (raw)
gpio-shared-proxy chooses its descriptor lock (mutex vs spinlock) from
the underlying chip's can_sleep, but under that lock it calls config and
direction ops that reach sleeping pinctrl paths. On a controller with
non-sleeping MMIO value ops the lock is a spinlock, so a sleeping call
runs from atomic context:
BUG: sleeping function called from invalid context
... pinctrl_gpio_set_config <- gpiochip_generic_config
<- gpio_shared_proxy_set_config (voting spinlock held)
<- ... <- mmc_pwrseq_simple_probe
This was reported on Khadas VIM3 and worked around for Amlogic by
commit 28f240683871 ("pinctrl: meson: mark the GPIO controller as
sleeping"), which marked the whole meson controller sleeping. That
workaround broke atomic value-path consumers: w1-gpio (1-Wire bitbang)
no longer detects devices, because its IRQ-disabled read slot calls the
non-cansleep gpiod_*_value() and now hits WARN_ON(can_sleep) per bit.
Patch 1 fixes the proxy locking generically (always a sleeping mutex).
Patch 2 then restores meson can_sleep=false, fixing 1-Wire.
Patch 1 has a trade-off: a proxied GPIO becomes sleeping, so consumers
gating on gpiod_cansleep() change behaviour. No current device needs
atomic (non-cansleep) value access on a shared GPIO -- every report
(Khadas VIM3, ODROID-M1, my test on JetHub D1+) is a shared reset line
(eMMC/SDIO pwrseq or PCIe reset) driven through the cansleep accessors,
which is what the proxy exists to vote on; bit-banging that needs atomic
access cannot work through voting anyway. An alternative that keeps
atomic value access (split locking) is possible but adds a second lock
and new race windows, so this series takes the simpler mutex-only
approach.
The two are a unit: patch 2 must not be applied without patch 1,
otherwise the original VIM3 splat returns on boards that share a meson
GPIO -- please keep the order. I have not Cc'd stable; I will request
stable backports separately once both patches have landed.
Changes since v2:
- gpio: shared-proxy: drop the set_func callback from
gpio_shared_proxy_set_unlocked() and call gpiod_set_value_cansleep()
directly. The shared direction_output path drives the already-output
line through the value setter instead of re-issuing
gpiod_direction_output() (equivalent, minus a redundant per-edge
re-assert of drive config/bias). No change to the voting/value
behaviour.
Changes since v1:
- gpio: shared-proxy: open-code the descriptor mutex; drop the
gpio_shared_desc_lock guard and the gpio_shared_lockdep_assert()
helper, move the mutex rationale to the can_sleep assignment.
v1: https://lore.kernel.org/linux-gpio/20260610153329.937833-1-v@baodeep.com/
v2: https://lore.kernel.org/linux-gpio/20260625115718.1678991-1-v@baodeep.com/
Viacheslav Bocharov (2):
gpio: shared-proxy: always serialize with a sleeping mutex
pinctrl: meson: restore non-sleeping GPIO access
drivers/gpio/gpio-shared-proxy.c | 76 ++++++++++-----------------
drivers/gpio/gpiolib-shared.c | 9 +---
drivers/gpio/gpiolib-shared.h | 28 +---------
drivers/pinctrl/meson/pinctrl-meson.c | 2 +-
4 files changed, 33 insertions(+), 82 deletions(-)
base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
--
2.54.0
WARNING: multiple messages have this Message-ID (diff)
From: Viacheslav Bocharov <v@baodeep.com>
To: Linus Walleij <linusw@kernel.org>, Bartosz Golaszewski <brgl@kernel.org>
Cc: Neil Armstrong <neil.armstrong@linaro.org>,
Kevin Hilman <khilman@baylibre.com>,
Jerome Brunet <jbrunet@baylibre.com>,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Robin Murphy <robin.murphy@arm.com>,
Diederik de Haas <diederik@cknow-tech.com>,
linux-gpio@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-amlogic@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: [PATCH v3 0/2] gpio: fix sleeping-in-atomic in shared-proxy; restore meson non-sleeping
Date: Tue, 30 Jun 2026 13:15:43 +0300 [thread overview]
Message-ID: <20260630101545.800625-1-v@baodeep.com> (raw)
gpio-shared-proxy chooses its descriptor lock (mutex vs spinlock) from
the underlying chip's can_sleep, but under that lock it calls config and
direction ops that reach sleeping pinctrl paths. On a controller with
non-sleeping MMIO value ops the lock is a spinlock, so a sleeping call
runs from atomic context:
BUG: sleeping function called from invalid context
... pinctrl_gpio_set_config <- gpiochip_generic_config
<- gpio_shared_proxy_set_config (voting spinlock held)
<- ... <- mmc_pwrseq_simple_probe
This was reported on Khadas VIM3 and worked around for Amlogic by
commit 28f240683871 ("pinctrl: meson: mark the GPIO controller as
sleeping"), which marked the whole meson controller sleeping. That
workaround broke atomic value-path consumers: w1-gpio (1-Wire bitbang)
no longer detects devices, because its IRQ-disabled read slot calls the
non-cansleep gpiod_*_value() and now hits WARN_ON(can_sleep) per bit.
Patch 1 fixes the proxy locking generically (always a sleeping mutex).
Patch 2 then restores meson can_sleep=false, fixing 1-Wire.
Patch 1 has a trade-off: a proxied GPIO becomes sleeping, so consumers
gating on gpiod_cansleep() change behaviour. No current device needs
atomic (non-cansleep) value access on a shared GPIO -- every report
(Khadas VIM3, ODROID-M1, my test on JetHub D1+) is a shared reset line
(eMMC/SDIO pwrseq or PCIe reset) driven through the cansleep accessors,
which is what the proxy exists to vote on; bit-banging that needs atomic
access cannot work through voting anyway. An alternative that keeps
atomic value access (split locking) is possible but adds a second lock
and new race windows, so this series takes the simpler mutex-only
approach.
The two are a unit: patch 2 must not be applied without patch 1,
otherwise the original VIM3 splat returns on boards that share a meson
GPIO -- please keep the order. I have not Cc'd stable; I will request
stable backports separately once both patches have landed.
Changes since v2:
- gpio: shared-proxy: drop the set_func callback from
gpio_shared_proxy_set_unlocked() and call gpiod_set_value_cansleep()
directly. The shared direction_output path drives the already-output
line through the value setter instead of re-issuing
gpiod_direction_output() (equivalent, minus a redundant per-edge
re-assert of drive config/bias). No change to the voting/value
behaviour.
Changes since v1:
- gpio: shared-proxy: open-code the descriptor mutex; drop the
gpio_shared_desc_lock guard and the gpio_shared_lockdep_assert()
helper, move the mutex rationale to the can_sleep assignment.
v1: https://lore.kernel.org/linux-gpio/20260610153329.937833-1-v@baodeep.com/
v2: https://lore.kernel.org/linux-gpio/20260625115718.1678991-1-v@baodeep.com/
Viacheslav Bocharov (2):
gpio: shared-proxy: always serialize with a sleeping mutex
pinctrl: meson: restore non-sleeping GPIO access
drivers/gpio/gpio-shared-proxy.c | 76 ++++++++++-----------------
drivers/gpio/gpiolib-shared.c | 9 +---
drivers/gpio/gpiolib-shared.h | 28 +---------
drivers/pinctrl/meson/pinctrl-meson.c | 2 +-
4 files changed, 33 insertions(+), 82 deletions(-)
base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
--
2.54.0
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
next reply other threads:[~2026-06-30 10:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-30 10:15 Viacheslav Bocharov [this message]
2026-06-30 10:15 ` [PATCH v3 0/2] gpio: fix sleeping-in-atomic in shared-proxy; restore meson non-sleeping Viacheslav Bocharov
2026-06-30 10:15 ` [PATCH v3 1/2] gpio: shared-proxy: always serialize with a sleeping mutex Viacheslav Bocharov
2026-06-30 10:15 ` Viacheslav Bocharov
2026-06-30 10:15 ` [PATCH v3 2/2] pinctrl: meson: restore non-sleeping GPIO access Viacheslav Bocharov
2026-06-30 10:15 ` Viacheslav Bocharov
2026-06-30 10:46 ` sashiko-bot
2026-06-30 14:03 ` (subset) [PATCH v3 0/2] gpio: fix sleeping-in-atomic in shared-proxy; restore meson non-sleeping Bartosz Golaszewski
2026-06-30 14:03 ` 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=20260630101545.800625-1-v@baodeep.com \
--to=v@baodeep.com \
--cc=brgl@kernel.org \
--cc=diederik@cknow-tech.com \
--cc=jbrunet@baylibre.com \
--cc=khilman@baylibre.com \
--cc=linusw@kernel.org \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=martin.blumenstingl@googlemail.com \
--cc=neil.armstrong@linaro.org \
--cc=robin.murphy@arm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.