Re: [PATCH v4 00/10] gpio: improve support for shared GPIOs

Bartosz Golaszewski
2025-11-26T16:50:13Z

On Wed, Nov 26, 2025 at 5:27 PM Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> wrote:
>
> I'm sorry if this was already reported and fixed. On Qualcomm RB5
> platform with this patchset in place I'm getting the following backtrace
> (and then a lockup):
>
> [ 4.298346] gpiolib_shared: GPIO 130 owned by f100000.pinctrl is shared by multiple consumers
> [ 4.307157] gpiolib_shared: Setting up a shared GPIO entry for speaker@0,3
> [ 4.314604]
> [ 4.316146] ============================================
> [ 4.321600] WARNING: possible recursive locking detected
> [ 4.327054] 6.18.0-rc7-next-20251125-g3f300d0674f6-dirty #3887 Not tainted
> [ 4.334115] --------------------------------------------
> [ 4.339566] kworker/u32:3/71 is trying to acquire lock:
> [ 4.344931] ffffda019ba71850 (gpio_shared_lock){+.+.}-{4:4}, at: devm_gpiod_shared_get+0x34/0x2e0
> [ 4.354057]
> [ 4.354057] but task is already holding lock:
> [ 4.360041] ffffda019ba71850 (gpio_shared_lock){+.+.}-{4:4}, at: gpio_device_setup_shared+0x30/0x268
> [ 4.369421]

Ah, I missed the use-case where the auxiliary device is bound right
after it gets added and we're still holding the shared_gpio_lock. I
think we should prepare the proxy devices but only add them after
releasing the lock. I will fix it first thing tomorrow morning.

Bartosz