Re: [PATCH 0/2] gpio: shared: another set of small fixes

[Marek Szyprowski <m.szyprowski@samsung.com>]

On 05.01.2026 17:53, Bartosz Golaszewski wrote:
> On Mon, 5 Jan 2026 17:48:05 +0100, Marek Szyprowski
> <m.szyprowski@samsung.com> said:
>> On 05.01.2026 16:52, Bartosz Golaszewski wrote:
>>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>>> ---
>>> Bartosz Golaszewski (2):
>>>         gpio: shared: assign the correct firmware node for reset-gpio use-case
>>>         gpio: shared: fix a race condition
>>>
>>>    drivers/gpio/gpiolib-shared.c | 4 +++-
>>>    1 file changed, 3 insertions(+), 1 deletion(-)
>>> ---
>>> base-commit: 19fb766a1e5ed5943a62fc671c09d45352a81b1d
>>> change-id: 20260105-gpio-shared-fixes-40a8ec3b6b25
>> Those patches indeed fixes some timing issues with the commit
>> 49416483a953 ("gpio: shared: allow sharing a reset-gpios pin between
>> reset-gpio and gpiolib"), but they also reveals another one. I've
>> initially thought that this is a false positive and needs only a proper
>> lockdep annotation, but some boards hang just after similar lockdep splat:
>>
>> ============================================
>> WARNING: possible recursive locking detected
>> 6.19.0-rc4-next-20260105+ #11974 Not tainted
>> --------------------------------------------
>> (udev-worker)/192 is trying to acquire lock:
>> ffff000004c15098 (&ref->lock){+.+.}-{4:4}, at:
>> gpio_shared_dev_is_reset_gpio+0xcc/0x234
>>
>> but task is already holding lock:
>> ffff000004c15898 (&ref->lock){+.+.}-{4:4}, at:
>> gpio_shared_add_proxy_lookup+0x98/0x228
>>
>> other info that might help us debug this:
>>    Possible unsafe locking scenario:
>>
>>          CPU0
>>          ----
>>     lock(&ref->lock);
>>     lock(&ref->lock);
>>
>>    *** DEADLOCK ***
>>
>>    May be due to missing lock nesting notation
>>
>> 3 locks held by (udev-worker)/192:
>>    #0: ffff00000b3ad8e8 (&dev->mutex){....}-{4:4}, at:
>> __driver_attach+0x90/0x1ac
>>    #1: ffff8000830f2600 (gpio_devices_srcu){.+.+}-{0:0}, at:
>> gpiod_find_and_request+0x0/0x574
>>    #2: ffff000004c15898 (&ref->lock){+.+.}-{4:4}, at:
>> gpio_shared_add_proxy_lookup+0x98/0x228
>>
> Ah this must be due to also trying to compare the ref to the base ref...
>
> Could you try to add the following on top:
>
> diff --git a/drivers/gpio/gpiolib-shared.c b/drivers/gpio/gpiolib-shared.c
> index 198951c4c80b..5f3b8bc4a4fc 100644
> --- a/drivers/gpio/gpiolib-shared.c
> +++ b/drivers/gpio/gpiolib-shared.c
> @@ -378,6 +378,9 @@ static bool gpio_shared_dev_is_reset_gpio(struct
> device *consumer,
>   	 * arguments match the ones from this consumer's node.
>   	 */
>   	list_for_each_entry(real_ref, &entry->refs, list) {
> +		if (real_ref == ref)
> +			continue;
> +
>   		guard(mutex)(&real_ref->lock);
>
>   		if (!real_ref->fwnode)
>
>
> If that works, I'll send a v2.

This fixed the hangs, but the lockdep whining is still there.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland