From: Linus Walleij <linusw@kernel.org>
To: Petar Stepanovic <pstepanovic@axiado.com>
Cc: Tzu-Hao Wei <twei@axiado.com>, Swark Yang <syang@axiado.com>,
Prasad Bolisetty <pbolisetty@axiado.com>,
Bartosz Golaszewski <brgl@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Harshit Shah <hshah@axiado.com>,
SriNavmani A <srinavmani@axiado.com>,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] dt-bindings: gpio: add Axiado SGPIO controller
Date: Thu, 7 May 2026 11:44:32 +0200 [thread overview]
Message-ID: <CAD++jLn4R9ubqHsek-56s1sF9YhxYt4-C2TPdYGcYjy2MC6q_Q@mail.gmail.com> (raw)
In-Reply-To: <106b7b64-ed6e-499f-b5ac-60c1277f2f03@axiado.com>
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.
Yours,
Linus Walleij
next prev parent reply other threads:[~2026-05-07 9:44 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-14 13:48 [PATCH 0/3] Subject: [PATCH 0/3] gpio: add support for Axiado SGPIO controller Petar Stepanovic
2026-04-14 13:48 ` [PATCH 1/3] dt-bindings: gpio: add " Petar Stepanovic
2026-04-14 14:06 ` Krzysztof Kozlowski
2026-04-24 7:26 ` Linus Walleij
2026-05-07 8:05 ` Petar Stepanovic
2026-05-07 9:44 ` Linus Walleij [this message]
2026-05-08 7:57 ` Petar Stepanovic
2026-05-11 8:36 ` Linus Walleij
2026-05-13 8:59 ` Petar Stepanovic
2026-05-23 9:13 ` Linus Walleij
2026-04-14 13:48 ` [PATCH 2/3] gpio: axiado: add SGPIO controller support Petar Stepanovic
2026-04-14 14:04 ` Krzysztof Kozlowski
2026-04-20 9:25 ` Bartosz Golaszewski
2026-04-24 7:44 ` Linus Walleij
2026-04-14 13:48 ` [PATCH 3/3] MAINTAINERS: add Axiado SGPIO controller Petar Stepanovic
2026-04-14 14:12 ` Krzysztof Kozlowski
2026-04-22 1:48 ` Prasad Bolisetty
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAD++jLn4R9ubqHsek-56s1sF9YhxYt4-C2TPdYGcYjy2MC6q_Q@mail.gmail.com \
--to=linusw@kernel.org \
--cc=brgl@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=hshah@axiado.com \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbolisetty@axiado.com \
--cc=pstepanovic@axiado.com \
--cc=robh@kernel.org \
--cc=srinavmani@axiado.com \
--cc=syang@axiado.com \
--cc=twei@axiado.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).