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 v2 0/2] gpio: fix sleeping-in-atomic in shared-proxy; restore meson non-sleeping
Date: Thu, 25 Jun 2026 14:57:16 +0300 [thread overview]
Message-ID: <20260625115718.1678991-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 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. No
functional change.
v1: https://lore.kernel.org/linux-gpio/20260610153329.937833-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 | 66 +++++++++++----------------
drivers/gpio/gpiolib-shared.c | 9 +---
drivers/gpio/gpiolib-shared.h | 28 +-----------
drivers/pinctrl/meson/pinctrl-meson.c | 2 +-
4 files changed, 30 insertions(+), 75 deletions(-)
base-commit: 840ef6c78e6a2f694b578ecb9063241c992aaa9e
--
2.54.0
next reply other threads:[~2026-06-25 11:59 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-25 11:57 Viacheslav Bocharov [this message]
2026-06-25 11:57 ` [PATCH v2 1/2] gpio: shared-proxy: always serialize with a sleeping mutex Viacheslav Bocharov
2026-06-25 11:57 ` [PATCH v2 2/2] pinctrl: meson: restore non-sleeping GPIO access Viacheslav Bocharov
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=20260625115718.1678991-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox