Re: [PATCH v3] gpio: shared: make the voting mechanism adaptable
From: Geert Uytterhoeven
Date: Tue Oct 20 2026 - 11:22:12 EST
Hi Bartosz,
On Tue, 30 Jun 2026 at 16:33, Bartosz Golaszewski
<bartosz.golaszewski@xxxxxxxxxxxxxxxx> wrote:
> The current voting mechanism in GPIO shared proxy assumes that "low" is
> always the default value and users can only vote for driving the GPIO
> "high" in which case it will remain high as long as there's at least one
> user voting.
>
> This makes it impossible to use the automatic sharing management for
> certain use-cases such as the write-protect GPIOs of EEPROMs which are
> requested "high" and driven "low" to enable writing. In this case, if
> the WP GPIO is shared by multiple EEPROMs, and at least one of them
> wants to enable writing, the pin must be set to "low".
>
> Modify the voting heuristic to assume the value set by the first user on
> request to be the "default" and subseqent calls to gpiod_set_value()
> will constitute votes for a change of the value to the opposite. In the
> wp-gpios case it will mean that the nvmem core requests the GPIO as
> "out-high" for all EEPROMs sharing the pin, and when one of them wants
> to write, the pin will be driven low, enabling it.
>
> Fixes: e992d54c6f97 ("gpio: shared-proxy: implement the shared GPIO proxy driver")
> Reported-by: Marek Vasut <marex@xxxxxxxxxxxx>
> Closes: https://lore.kernel.org/all/20260511163518.51104-1-marex@xxxxxxxxxxxx/
> Reviewed-by: Linus Walleij <linusw@xxxxxxxxxx>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxxxxxxxx>
Thanks for your patch, which is now commit b30973e8c3920ddf ("gpio:
shared: make the voting mechanism adaptable") in v7.2. I only
noticed this now, thanks to commit f918e38044988082 ("arm64: enable
HAVE_SHARED_GPIOS for all ARM64 platforms") in soc/for-next.
So far I haven't seen any ill behavior due to that yet.
However, shouldn't the default state depend on GPIO_ACTIVE_{HIGH,LOW}
and/or GPIO_OPEN_{DRAIN,SOURCE}?
Apparently Marek asked the same question[1], to which you replied[2]:
"We could but that would require DT changes, you probably don't want
this?"
Can you please elaborate why this would require DT changes?
Thanks!
[1] https://lore.kernel.org/3612f5f6-eeca-49e5-9662-72729bb48c9f@xxxxxxxxxxxx/
[2] https://lore.kernel.org/CAMRc=Mf_B+=adsEu+4TTBdKHdVSf2uWH+11WH9uz-h4Q0BS-VA@xxxxxxxxxxxxxx/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds