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

[Linus Walleij]

On Fri, May 8, 2026 at 9:57 AM Petar Stepanovic <pstepanovic at axiado.com> wrote:

> For example, when SGPIO is configured for 128 lines, the hardware provides
> 128 input bits (DIN) and 128 output bits (DOUT). If modeled directly, this
> corresponds to 256 GPIOs in Linux, since the input and output signals are
> independent and are not bidirectional.

I don't get it.

Linux internals are modeled after physical GPIO lines, actual rails
you can control. ngpios for example means the number of controllable
physical lines.

What kind of bits exist in some registers does not concern this
concept.

Please check this presentation page 24 for example:
https://www.df.lth.se/~triad/papers/pincontrol.pdf

The fact that there exist many weird things inside the SoC
doesn't alter the fact that "a GPIO" is an abstraction for a single
physical I/O entity such as a line/pad/pin.

> Similar to the gpio-aspeed-sgpio.c driver, the input and output paths are
> fixed by hardware and cannot be configured dynamically per line. These are
> not interchangeable directions of the same GPIO line;

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.

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

Yours,
Linus Walleij