Re: [PATCH 0/2] Fix sharing a PMIC GPIO between multiple consumers

[Bartosz Golaszewski]

On Tue, 15 Sep 2026 03:44:45 +0200, Shawn Guo
<shengchao.guo@xxxxxxxxxxxxxxxx> said:
> On the Qualcomm Nord boards, three discrete regulators feeding a WCN7850
> module are gated by a single PMIC GPIO (pmau0102_e GPIO6), so the board DT
> describes three regulator-fixed nodes pointing at the same GPIO.  Only the
> first of them probes:
>
>   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
>   platform wcn7850-pmu: deferred probe pending: supplier regulator-wcn-core-vh-1p95 not ready
>
> ARCH_QCOM selects HAVE_SHARED_GPIOS, so gpiolib creates shared GPIO proxies
> for the line rather than taking the legacy nonexclusive path.  The failure
> turns out to have two independent causes, one on each side of that
> interface.
>
> On the provider side, neither of spmi-gpio's direction callbacks clears the
> opposite buffer: .direction_output() only sets output_enabled and
> .direction_input() only sets input_enabled.  A pad left in DIGITAL_INPUT
> mode by the bootloader therefore ends up in DIGITAL_INPUT_OUTPUT mode on
> the first direction change, after which .get_direction() reports
> GPIO_LINE_DIRECTION_IN even though the driver is driving the line.  The
> same asymmetry means gpiod_direction_input() never stops driving a pad that
> was previously an output, which is a bug in its own right.
>
> On the consumer side, gpio_shared_proxy_direction_output() reads the
> direction back for every requester after the first and refuses with -EPERM
> if it sees an input.  The readback is not needed, since the proxy is the
> only entity configuring the line and already knows which direction it
> asked for.  It is also not robust: a provider without .get_direction() at
> all makes gpiochip_get_direction() return -EOPNOTSUPP under a WARN_ON,
> which the proxy propagates just the same.
>
> Either patch on its own is enough to make the board work; both are sent
> because both describe real bugs.  Patch 1 is what makes shared GPIOs work
> irrespective of the provider, so I would consider it the more important of
> the two.  There is no build or apply dependency between them and they
> touch different subsystems, so they can go through separate trees.
>

I responded to patch 1/2 before reading this bit. Ok, I'm not against 1/2,
I'll queue it for fixes.

Bart