Re: [PATCH 1/2] gpio: shared-proxy: track direction instead of reading it back

[Bartosz Golaszewski]

On Tue, 15 Sep 2026 03:44:46 +0200, Shawn Guo
<shengchao.guo@xxxxxxxxxxxxxxxx> said:
> On boards where more than one consumer shares a Qualcomm SPMI PMIC GPIO,
> all but the first consumer fail to configure the line as output:
>
>   reg-fixed-voltage regulator-wcn-core-vm-1p35: setup of GPIO (default) failed: -1
>   reg-fixed-voltage regulator-wcn-core-vm-1p35: error -EPERM: can't get GPIO
>
> The first consumer takes the usecnt == 1 branch and really does set the
> underlying line to output.  Later consumers instead read the direction
> back with gpiod_get_direction() and refuse with -EPERM if it reports
> input.  pmic_gpio_get_direction() derives the direction from the pad's
> input buffer (pad->input_enabled), which pmic_gpio_direction_output()
> never clears, so a pad whose input buffer is enabled at power-up reports
> input forever and the proxy rejects every consumer after the first.
>
> The readback is not needed: the proxy is the only entity configuring the
> line, so it already knows which direction it asked for.  Record that in
> struct gpio_shared_desc and compare against the recorded value.  Keep a
> readback in the get_direction() callback for the case where no proxy has
> configured the line yet, and reset the recorded direction once the last
> user goes away so that the next requester establishes it again.
>
> Assisted-by: LLM
> Fixes: e992d54c6f97 ("gpio: shared-proxy: implement the shared GPIO proxy driver")
> Signed-off-by: Shawn Guo <shengchao.guo@xxxxxxxxxxxxxxxx>
> ---

I think sashiko is correct about the GPIOD_ASIS use-case. I think this is why
I used an unconditional read-back in the first place actually.

Bart