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

[Shawn Guo <shengchao.guo@oss.qualcomm.com>]

On Wed, Sep 16, 2026 at 04:00:01AM -0500, Bartosz Golaszewski wrote:
> On Tue, 15 Sep 2026 03:44:46 +0200, Shawn Guo
> <shengchao.guo@oss.qualcomm.com> 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@oss.qualcomm.com>
> > ---
> 
> I think sashiko is correct about the GPIOD_ASIS use-case.

I didn't receive any comments from sashiko. Could you point me to it?

Shawn

> I think this is why
> I used an unconditional read-back in the first place actually.