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: Mon, 11 May 2026 10:36:23 +0200 [thread overview]
Message-ID: <CAD++jL=51iWK2SyxoWOTxSQHAq-Frd0mm6cPxqYu81qifFfHGg@mail.gmail.com> (raw)
In-Reply-To: <fd2ee102-db52-4a37-b96e-c16211e3d8e3@axiado.com>
On Fri, May 8, 2026 at 9:57 AM Petar Stepanovic <pstepanovic@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
next prev parent reply other threads:[~2026-05-11 8:36 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
2026-05-08 7:57 ` Petar Stepanovic
2026-05-11 8:36 ` Linus Walleij [this message]
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++jL=51iWK2SyxoWOTxSQHAq-Frd0mm6cPxqYu81qifFfHGg@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).