| Message ID | 20251009223501.570949-2-jelonek.jonas@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | add support for splitting GPIOs | expand |
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
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@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
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>; + }; + };
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