linux-kernel - Re: [RFC PATCH v1 1/2] dt-bindings: gpio: add gpio-split controller

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACRpkdb6bTFbTtNsO59GXFa9eMK9x=+BGK5Vx4bKv62wxiSpiw@mail.gmail.com>
Date: Tue, 14 Oct 2025 10:23:06 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Jonas Jelonek <jelonek.jonas@...il.com>, Peter Rosin <peda@...ntia.se>, 
	Geert Uytterhoeven <geert+renesas@...der.be>
Cc: Bartosz Golaszewski <brgl@...ev.pl>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, linux-gpio@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v1 1/2] dt-bindings: gpio: add gpio-split controller

Hi Jonas,

thanks for your patch!

Including Peter Rosin (the gpio-mux author) and Geert Uytterhoeven
on this review, as they have worked with similar stuff. Please include
them on future postings. The result definitely need Peters ack before
we can merge it.

On Fri, Oct 10, 2025 at 12:35 AM Jonas Jelonek <jelonek.jonas@...il.com> wrote:

> Add dt-schema for a virtual gpio-split controller which exposes virtual
> GPIOs for a shared GPIO controlled by a multiplexer, e.g. a gpio-mux.
>
> The gpio-split controller is a gpio-controller, thus has mostly the same
> semantics. However, it requires a mux-control to be specified upon which
> it will operate.
>
> Signed-off-by: Jonas Jelonek <jelonek.jonas@...il.com>

So if I understand it correctly this models a 1-to-many input-only
GPIO multiplexer, we need an illustration such as

        +----- A
IN     /
<-----o------- B
    / |\
    | | +----- C
    | |  \
    | |   +--- D
    | |
   M1 M0

MUX CONTROL

 M1 M0   INPUT
  0  0   A
  0  1   B
  1  0   C
  1  1   D

Is this correct? In that case include something like this
verbatim in the bindings (feel free to copy/modify this)
as it makes it much easier to understand what is going on.

That's a very minimal example of a way to turn 3 GPIO
lines into 4 GPIO lines, which is a bit crazy but I'm not
the one to tell vendors what to do :D

> +  mux-controls:
> +    maxItems: 1

So this needs a description, it is a phandle to the
gpio multiplexer (reference /schemas/mux/gpio-mux.yaml
explicitly!) used by the splitter.

You should also in the same patch add an example to
/schemas/mux/gpio-mux.yaml showing how this is used
to muliplex GPIOs so people find this new usecase easily.

> +  shared-gpio:
> +    description:
> +      GPIO that is shared by the virtual GPIOs and controlled via the mux.

So this one is shared one-to-many, and I think the bindings
overall makes sense.

Maybe "gpio-split" is a bit ambiguous?
We have io-channel-mux, so what about "gpio-line-mux"
simply?

The fact that GPIO lines are used to do the muxing is just
a detail since a mux is an abstract concept, it could have
just as well been muxed with some I2C device for example.

Yours,
Linus Walleij