Re: [PATCH v3] gpio: shared: make the voting mechanism adaptable

[Bartosz Golaszewski]

On Tue, 20 Oct 2026 16:30:24 +0200, Geert Uytterhoeven
<geert@xxxxxxxxxxxxxx> said:
> Hi Bartosz,
>
> 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.
>

This has been tested quite extensively on Qualcomm platforms and is being
currently used upstream, but if you ever notice any issue, please do report
it, I'll do my best to fix it ASAP.

> However, shouldn't the default state depend on GPIO_ACTIVE_{HIGH,LOW}
> and/or GPIO_OPEN_{DRAIN,SOURCE}?
>

It does though, doesn't it? If you have:

	node0 {
		foo-gpios = <&xyz 0 GPIO_ACTIVE_LOW>;
	};

	node1 {
		foo-gpios = <&xyz 0 GPIO_ACTIVE_LOW>;
	};

And the driver that requests this shared pin over the proxy goes:

	desc = gpiod_get(dev, "foo", GPIOD_OUT_HIGH);

The actual value written to hardware will be "low". The value in the shared
proxy's memory may as well be 1/high but it doesn't matter because the proxy
tracks the logical value.

> 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?
>

Sure, and my response was actually a bit longer:

    "We could but that would require DT changes, you probably don't want
    this? That's a different thing though too. Here's it's purely logical
    - either we default to high and vote for low or default to low and
    vote for high with at least one vote needed to switch."

We were talking about the specific case of a write-protect pin, which is held
high by default and pulled low for writing. This logic is the same irrespective
of the ACTIVE_LOW setting.

Bart