Re: [PATCH 0/2] gpio: fix sleeping-in-atomic in shared-proxy; restore meson non-sleeping

[Robin Murphy]

On 11/06/2026 9:26 am, Marek Szyprowski wrote:
> Hi Viachesla,
>
> On 10.06.2026 17:32, Viacheslav Bocharov wrote:
> > 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. An alternative that keeps
> > atomic value access (split locking) is possible but adds a second lock
> > and new race windows. I went with the simpler, verified approach and
> > would appreciate guidance on whether the atomic value path must be
> > preserved.
> >
> > 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.
> >
> > Viacheslav Bocharov (2):
> >    gpio: shared-proxy: always serialize with a sleeping mutex
> >    pinctrl: meson: restore non-sleeping GPIO access
>
> Tested-by: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx>
>
> This probably also affects the similar changes in Rockchip GPIO driver done
> by the following commits:
> 20cf2aed89ac ("gpio: rockchip: mark the GPIO controller as sleeping")
> 7ca497be0016 ("gpio: rockchip: Stop calling pinctrl for set_direction")
>
> I've checked this patchset with these two reverted and no warning was reported.

If it hadn't already been fixed, then indeed I guess this might make 
20cf2aed89ac redundant. However, 7ca497be0016 is still an objective 
improvement either way, since that driver never needed to call pinctrl 
at all (it was seemingly just an artefact of how the GPIO code was 
originally implemented within the pinctrl driver itself).

Thanks,
Robin.