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@gmail.com>
---
.../devicetree/bindings/gpio/gpio-split.yaml | 77 +++++++++++++++++++
1 file changed, 77 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-split.yaml
diff --git a/Documentation/devicetree/bindings/gpio/gpio-split.yaml b/Documentation/devicetree/bindings/gpio/gpio-split.yaml
new file mode 100644
index 000000000000..9a58c81da4fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-split.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/gpio-split.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GPIO split
+
+maintainers:
+ - Jonas Jelonek <jelonek.jonas@gmail.com>
+
+description:
+ A virtual GPIO controller to provide virtual GPIOs backed by a single real
+ GPIO and a multiplexer. This controller may be used in case a real GPIO is
+ connected to multiple inputs/outputs and controlled by a multiplexer, and
+ another subsystem/driver is not able to work with multiplexer subsystem.
+
+properties:
+ compatible:
+ const: gpio-split
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+
+ gpio-line-names: true
+
+ mux-controls:
+ maxItems: 1
+
+ ngpios: false
+
+ shared-gpio:
+ description:
+ GPIO that is shared by the virtual GPIOs and controlled via the mux.
+
+required:
+ - compatible
+ - gpio-controller
+ - mux-controls
+ - shared-gpio
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/mux/mux.h>
+
+ sfp_gpio_mux: gpio-mux {
+ compatible = "gpio-mux";
+ mux-gpios = <&gpio0 12 GPIO_ACTIVE_HIGH>,
+ <&gpio0 14 GPIO_ACTIVE_HIGH>;
+ #mux-control-cells = <0>;
+ idle-state = <MUX_IDLE_AS_IS>;
+ };
+
+ sfp1_gpio: sfp-gpio-1 {
+ compatible = "gpio-split";
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ mux-controls = <&sfp_gpio_mux>;
+ shared-gpio = <&gpio0 19 GPIO_ACTIVE_HIGH>;
+
+ gpio-line-names = "SFP1_LOS", "SFP1_MOD_ABS", "SFP1_TX_FAULT";
+ gpio-0 {
+ mux-state = <0>;
+ };
+ gpio-1 {
+ mux-state = <1>;
+ };
+ gpio-2 {
+ mux-state = <3>;
+ };
+ };
--
2.48.1Hi 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@gmail.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@gmail.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
Hi Linus, On 14.10.25 10:23, Linus Walleij wrote: > 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. Thanks, will do. > 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. You nailed it. I'll include your drawing in the bindings then in the next revision. Only thing is that I just didn't limit it to being 'input-only'. I have no real usecase for this but to me there was no really obvious issue needing this to be input-only. > 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 On my device it's actually that the single GPIO mux controls the signals for both SFP cages, meaning it makes more sense in the big picture though a GPIO expander as all other vendors do would've been better IMO ^^. >> + 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. Sure, will add it. >> + 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. I'll also add this hint to the description to make it clearer. > 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. Sure, this was just my initial idea but I'm not fixed to it. I can adjust that in the next iteration. > Yours, > Linus Walleij Best, Jonas
On 10/10/2025 07:35, Jonas Jelonek wrote: > diff --git a/Documentation/devicetree/bindings/gpio/gpio-split.yaml b/Documentation/devicetree/bindings/gpio/gpio-split.yaml > new file mode 100644 > index 000000000000..9a58c81da4fa > --- /dev/null > +++ b/Documentation/devicetree/bindings/gpio/gpio-split.yaml > @@ -0,0 +1,77 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/gpio/gpio-split.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: GPIO split > + > +maintainers: > + - Jonas Jelonek <jelonek.jonas@gmail.com> > + > +description: > + A virtual GPIO controller to provide virtual GPIOs backed by a single real > + GPIO and a multiplexer. This controller may be used in case a real GPIO is > + connected to multiple inputs/outputs and controlled by a multiplexer, and > + another subsystem/driver is not able to work with multiplexer subsystem. Instead, please fix the subsystem driver? I have also doubts we actually want it in DT, because we tie the limitation of Linux drivers to bindings. Best regards, Krzysztof
Hi Krzysztof, On 10.10.25 03:12, Krzysztof Kozlowski wrote: > Instead, please fix the subsystem driver? That's why I sent this as an RFC. I thought about this too but have no good idea how to represent this in DT while keeping the existing bindings. So I just thought this small driver would be the easier way, possibly being useful for other potential usecases. But sure, if this is the only way to go I'll have to RFC this at the SFP driver side asking for any ideas how this could be achieved. > I have also doubts we actually want it in DT, because we tie the > limitation of Linux drivers to bindings. > > > Best regards, > Krzysztof Best regards, Jonas
© 2016 - 2025 Red Hat, Inc.