Re: [PATCH] gpio: shared: handle the reset-gpios corner case

[Bartosz Golaszewski]

On Tue, Nov 25, 2025 at 12:05 AM Val Packett <val@xxxxxxxxxxxx> wrote:
>
>
> On 11/24/25 12:36 PM, Bartosz Golaszewski wrote:
> > On Mon, Nov 24, 2025 at 9:38 AM Bartosz Golaszewski <brgl@xxxxxxxx> wrote:
> >> On Sun, Nov 23, 2025 at 2:03 AM Val Packett <val@xxxxxxxxxxxx> wrote:
> >>>> ---
> >>>> This is targetting linux-next where the reset-gpio driver is now using
> >>>> the auxiliary bus and software nodes rather than the platform bus and
> >>>> GPIO machine lookup. The bug is the same in both cases but the fix would
> >>>> be completely different.
> >>>> ---
> >>>> [..]
> >>> Tried applying only this, as well as this +
> >>> https://lore.kernel.org/all/20251120-reset-gpios-swnodes-v7-0-a100493a0f4b@xxxxxxxxxx/
> >>> + https://lore.kernel.org/all/20251121135739.66528-1-brgl@xxxxxxxx/ (on
> >>> top of next-20251120) and the issue is still present.. am I missing
> >>> something?
> >> Can you try this branch?
> >>
> >>    https://github.com/brgl/linux test/gpiolib-shared-reset-gpio-fix
> >>
> >> I confirmed it works on my setup and fixes the problem with multiple
> >> users of reset-gpio AND shared GPIOs enabled.
> > Actually linux-next got updated with all the prerequisites so you can
> > try this patch on top of next-20251124. I tested it and it works for
> > me. If it still doesn't for you, can you enable GPIO debug messages
> > and send me the entire kernel log?
> >
> > Bartosz
>
> Rebased to next-20251124, still the same..
>
> Here's a full dmesg: https://owo.packett.cool/lin/sound.gpio.dmesg
>
> I even added a custom print to confirm the reason of the EBUSY:
>
> [    9.233613] gpiolib: swnode: swnode_find_gpio: parsed 'reset-gpios'
> property of node 'node4[0]' - status (0)
> [    9.233624] gpiolib_shared: Adding machine lookup entry for a shared
> GPIO for consumer reset.gpio.0, with key 'gpiolib_shared.proxy.8' and
> con_id 'reset'
> [    9.233630] reset_gpio reset.gpio.0: using lookup tables for GPIO lookup
> [    9.233640] gpio_shared_proxy gpiolib_shared.proxy.8: Shared GPIO
> requested, number of users: 1
> [    9.233652] gpio_shared_proxy gpiolib_shared.proxy.8: Only one user
> of this shared GPIO, allowing to set direction to output with value 'low'
> [    9.332317] reset_gpio reset.gpio.1: using swnode 'node5' for 'reset'
> GPIO lookup
> [    9.332337] gpiolib: swnode: swnode_find_gpio: parsed 'reset-gpios'
> property of node 'node5[0]' - status (0)
> [    9.332343] gpiolib_shared: Adding machine lookup entry for a shared
> GPIO for consumer reset.gpio.1, with key 'gpiolib_shared.proxy.8' and
> con_id 'reset'
> [    9.332347] reset_gpio reset.gpio.1: using lookup tables for GPIO lookup
> [    9.332353] gpio-856 (reset): gpiod_request_commit: flags 200043
> test_and_set_bit GPIOD_FLAG_REQUESTED -> EBUSY
> [    9.332356] gpio-856 (reset): gpiod_request: status -16
> [    9.332358] reset_gpio reset.gpio.1: error -EBUSY: Could not get
> reset gpios
> [    9.332362] reset_gpio reset.gpio.1: probe with driver reset_gpio
> failed with error -16
> [    9.441612] wcd938x_codec audio-codec: bound sdw:2:0:0217:010d:00:4
> (ops wcd_sdw_component_ops [snd_soc_wcd_common])
> [    9.441644] wcd938x_codec audio-codec: bound sdw:3:0:0217:010d:00:3
> (ops wcd_sdw_component_ops [snd_soc_wcd_common])
> [    9.445771] gpio_shared_proxy gpiolib_shared.proxy.8: Voted for value
> 'high', effective value is 'high', number of votes for 'high': 1
>

Ok, so the checking in v1 was no strict enough to cover the use-case
of two reset-gpio devices consuming different pins from the same
controller. Please see v2 that I just sent. I reproduced the issue you
reported here and it fixed it.

Bart