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

[Petar Stepanovic <pstepanovic@axiado.com>]

Hi Linus,
Thanks for the feedback.

On 5/7/2026 11:44 AM, Linus Walleij wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> Hi Petar,
>
> On Thu, May 7, 2026 at 10:06 AM Petar Stepanovic <pstepanovic@axiado.com> 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.

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.

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; they are separate input
and output signals. Because of that, combining them into a single logical GPIO
abstraction would not accurately represent the hardware model.

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.

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?

>
> Yours,
> Linus Walleij

Thanks again for the guidance.

Best regards,
Petar Stepanovic