Re: [PATCH 1/3] dt-bindings: gpio: add Axiado SGPIO controller

[Petar Stepanovic <pstepanovic@axiado.com>]

On 5/11/2026 10:36 AM, Linus Walleij wrote:
> Are they connected to the same physical output line/pin or
> not? That is the only thing that matters. If they in the end control
> the same physical entitiy, it *is* the same GPIO line from Linux'
> point of view.
No, they are not connected to the same physical line/pin.

DIN and DOUT are separate physical SGPIO signals in this hardware. DIN
signals are input-only and DOUT signals are output-only; they are not
bidirectional or interchangeable paths for the same physical pin.

So I agree that Linux should model physical GPIO entities rather than
internal register bits. My previous wording was not clear enough: the
intention was to describe separate physical SGPIO signals, not just separate
register fields.
>> Because the direction is fixed by hardware, the standard
>> lines-initial-states property, which encodes both direction and initial state,
>> does not map cleanly to this design.
> GPIOs with fixed direction is nothing new for Linux, we've had
> that for ages.
>
> I would just have the driver reject configurations that does
> not apply and bail out.
>
> If you absolutely want to enforce the lines-initial-states to match what the
> hardware can do, then use YAML schema restriuctions on what
> values can be encoded into that array.
>
>> For the output lines (DOUT), should their initial values be described in the
>> device tree, or should they be configured by userspace, with the driver only
>> providing default initialization?
> I don't see why userspace should deal with that. The Linux userspace
> ABI is for hacking and odd usecases (like industrial). The nominal
> use is kernel-internal consumers and those must be able to
> request their GPIOs as well without any userspace shenanigans.
>
> But avoiding to deal with initial line states at all is a solution
> of course.
>
> What I don't understand is what purpose this dout-init actually
> does and why it cannot be set dynamically by the driver at runtime.

Some SGPIO outputs may control host-critical signals. For example, if the
BMC reboots while the host/server remains powered on, changing SGPIO output
values during driver initialization could potentially reset or shut down the
running host.

The purpose of `dout-init` is to provide a deterministic safe output state
during SGPIO initialization, before any GPIO consumer has requested the line.

That said, if the preferred approach is to preserve the existing hardware
DOUT state during probe and only change the value when a GPIO consumer
requests the line, I can rework the driver in that direction.

Thnaks,
Petar