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

[Linus Walleij]

Hi Petar,

On Thu, May 7, 2026 at 10:06 AM Petar Stepanovic <pstepanovic@xxxxxxxxxx> wrote:

> >> +  '#gpio-cells':
> >> +    const: 2
> > Are you sure you don't want to use 3 here instead and split the 128
> > GPIOs into 4 "banks" second cell being the bank number?
> > <&gpio 2 4>; ?
> >
> > Maybe this also solves the 512 GPIO by grouping the GPIOs into
> > 8 banks...?
>
> Thank you for the suggestion. We would prefer to keep #gpio-cells = <2>
> to stay aligned with existing SGPIO drivers and current DTS usage.
> A single linear offset is sufficient to identify each GPIO, so introducing a
> bank cell would add additional complexity without a clear benefit.
> Any internal bank handling can remain within the driver if needed.

If each bank also has its own associated IRQ line, for instance, then
this also reflects the hardware in a better way. But it seems this
controller has just one single IRQ line for all GPIOs, so maybe
this is better.

> >> +  ngpios:
> >> +    description: The number of gpios this controller has.
> >> +    $ref: /schemas/types.yaml#/definitions/uint32
> >
> > Same here, certainly the 128 variant has 128 gpios and
> > the 512 has 512 GPIOs? Just use the compatible string
> > to infer this.
>
> This seems to be platform-specific rather than strictly hardware-dependent.
> We were considering keeping it as a separate property (possibly renamed to |axiado,sgpio-ngpios|).
> Would you prefer that, or deriving it from the compatible string?

In this case it is fine to use ngpios.

ngpios is used when the hardware can actually do more
GPIO lines, but they are not routed out on the package of
the silicon, for example.

> >> +  dout-init:
> >> +    description: Initial values for the dout registers.
> >> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> >> +    minItems: 4
> >> +    maxItems: 4
> > In:
> > Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml
> >
> > you find:
> >
> >   lines-initial-states:
> >     $ref: /schemas/types.yaml#/definitions/uint32
> >     description:
> >       Bitmask that specifies the initial state of each line.
> >       When a bit is set to zero, the corresponding line will be initialized to
> >       the input (pulled-up) state.
> >       When the  bit is set to one, the line will be initialized to the
> >       low-level output state.
> >       If the property is not specified all lines will be initialized to the
> >       input state.
> >
> > If this is what you want, use this standard binding instead.
>
> In our case, the hardware provides dedicated DOUT registers where
> each bit directly controls the output level (0 = low, 1 = high).
>
> The lines-initial-states property also encodes input state semantics,
> so it does not map directly to this hardware.
>
> Would you prefer adapting to lines-initial-states despite this,
> or using a separate property for output initialization?

Please use lines-initial-states, support also input mode setting
and write more than one register if necessary.

Setting up the dout-states for lines which are supposed to be used
as inputs just doesn't make sense does it?

It is better if the device tree has this deeper semantic which
provides useful information for the developer and makes the
author of the device tree be more careful and detail-oriented
around the actual usecase.

Yours,
Linus Walleij