[RFC PATCH v1 0/2] add support for splitting GPIOs

[RFC PATCH v1 0/2] add support for splitting GPIOs

[Jonas Jelonek]

Hereby I propose a new type of virtual GPIO controller and corresponding
driver for splitting GPIOs using a multiplexer for different usecases.
Existing drivers apparently do not serve the purpose for what I need.

I came across an issue with a switch device from Zyxel which has two
SFP+ cages. Most similar switches either wire up the SFP signals
(RX_LOS, MOD_ABS, TX_FAULT, TX_DISABLE) directly to the SoC (if it has
enough GPIOs) or two a GPIO expander (for which a driver usually
exists). However, Zyxel decided to do it differently in the following
way:
  The signals RX_LOS, MOD_ABS and TX_FAULT share a single GPIO line to
  the SoC. Which one is actually connected to that GPIO line at a time
  is controlled by a separate multiplexer, a GPIO multiplexer in this
  case (which uses two other GPIOs). Only the TX_DISABLE is separate.

The SFP core/driver doesn't seem to support such a usecase for now, for
each signal one needs to specify a separate GPIO like:

  los-gpio = <&gpio0 0 GPIO_ACTIVE_HIGH>;
  mod-def0-gpio = <&gpio0 1 GPIO_ACTIVE_LOW>;
  ...

But for my device, I actually need to directly specify multiplexing
behavior in the SFP node or provide a mux-controller with 'mux-control'.

To fill this gap, I created a dt-schema and a working driver which
exactly does what is needed. It takes a phandle to a mux-controller and
the 'shared' gpio, and provides several virtual GPIOs based on the
children nodes defined for the gpio-split controller, each with a
mux-state which is used on access.

This virtual gpio-controller can then be referenced in the '-gpio'
properties of the SFP node (or other nodes depending on the usecase) as
usual and do not require any modification to the SFP core/driver.

--
Jonas Jelonek (2):
  dt-bindings: gpio: add gpio-split controller
  gpio: add gpio-split driver

 .../devicetree/bindings/gpio/gpio-split.yaml  |  77 +++++++
 MAINTAINERS                                   |   6 +
 drivers/gpio/Kconfig                          |   8 +
 drivers/gpio/Makefile                         |   1 +
 drivers/gpio/gpio-split.c                     | 210 ++++++++++++++++++
 5 files changed, 302 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-split.yaml
 create mode 100644 drivers/gpio/gpio-split.c


base-commit: bc061143637532c08d9fc657eec93fdc2588068e
-- 
2.48.1

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

[Jonas Jelonek]

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.1

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

[Krzysztof Kozlowski]

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

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

[Jonas Jelonek]

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

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

[Linus Walleij]

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

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

[Jonas Jelonek]

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

[RFC PATCH v1 2/2] gpio: add gpio-split driver

[Jonas Jelonek]

Add a new driver which allows to split a physical GPIO into multiple
virtual GPIOs by using a multiplexer.

For now, this doesn't support advanced features like IRQs, just normal
IN and OUT functionality of GPIOs.

This can help in various usecases. One practical case is the special
hardware design of the Realtek-based XS1930-10 switch from Zyxel. It
features two SFP+ ports/cages whose signals are wired to directly to the
switch SoC. Although Realtek SoCs are short on GPIOs, there are usually
enough the fit the SFP signals without any hacks.

However, Zyxel did some weird design and connected RX_LOS, MOD_ABS and
TX_FAULT of one SFP cage onto a single GPIO line controlled by a
multiplexer (the same for the other SFP cage). The single multiplexer
controls the lines for both SFP and depending on the state, the
designated 'signal GPIO lines' are connected to one of the three SFP
signals.

Because the SFP core/driver doesn't support multiplexer but needs single
GPIOs for each of the signals, this driver fills the gap between both.
It registers a gpio_chip, provides multiple virtual GPIOs and sets the
backing multiplexer accordingly.

Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
---
 MAINTAINERS               |   6 ++
 drivers/gpio/Kconfig      |   8 ++
 drivers/gpio/Makefile     |   1 +
 drivers/gpio/gpio-split.c | 210 ++++++++++++++++++++++++++++++++++++++
 4 files changed, 225 insertions(+)
 create mode 100644 drivers/gpio/gpio-split.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 681fbc825805..efb7e4a338e0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10479,6 +10479,12 @@ F:	Documentation/dev-tools/gpio-sloppy-logic-analyzer.rst
 F:	drivers/gpio/gpio-sloppy-logic-analyzer.c
 F:	tools/gpio/gpio-sloppy-logic-analyzer.sh
 
+GPIO SPLIT
+M:	Jonas Jelonek <jelonek.jonas@gmail.com>
+S:	Maintained
+F:	Documentation/devicetree/bindings/gpio/gpio-split.yaml
+F:	drivers/gpio/gpio-split.c
+
 GPIO SUBSYSTEM
 M:	Linus Walleij <linus.walleij@linaro.org>
 M:	Bartosz Golaszewski <brgl@bgdev.pl>
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 867d82b5ed63..9209bc78bd53 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -1988,6 +1988,14 @@ config GPIO_MOCKUP
 	  tools/testing/selftests/gpio/gpio-mockup.sh. Reference the usage in
 	  it.
 
+config GPIO_SPLIT
+	tristate "GPIO split driver"
+	depends on OF_GPIO
+	select MULTIPLEXER
+	help
+	  Say Y here to support splitting physical GPIOs into multiple virtual
+	  GPIOs using a multiplexer.
+
 config GPIO_VIRTIO
 	tristate "VirtIO GPIO support"
 	depends on VIRTIO
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 000fa2e397c2..813eb676e5fb 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -167,6 +167,7 @@ obj-$(CONFIG_GPIO_SLOPPY_LOGIC_ANALYZER) += gpio-sloppy-logic-analyzer.o
 obj-$(CONFIG_GPIO_SODAVILLE)		+= gpio-sodaville.o
 obj-$(CONFIG_GPIO_SPACEMIT_K1)		+= gpio-spacemit-k1.o
 obj-$(CONFIG_GPIO_SPEAR_SPICS)		+= gpio-spear-spics.o
+obj-$(CONFIG_GPIO_SPLIT)		+= gpio-split.o
 obj-$(CONFIG_GPIO_SPRD)			+= gpio-sprd.o
 obj-$(CONFIG_GPIO_STMPE)		+= gpio-stmpe.o
 obj-$(CONFIG_GPIO_STP_XWAY)		+= gpio-stp-xway.o
diff --git a/drivers/gpio/gpio-split.c b/drivers/gpio/gpio-split.c
new file mode 100644
index 000000000000..78da8bf91a0f
--- /dev/null
+++ b/drivers/gpio/gpio-split.c
@@ -0,0 +1,210 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * GPIO splitter acting as virtual gpiochip which "splits" a physical GPIO into
+ * multiple using a multiplexer (e.g. SFP signals RX_LOS, TX_FAULT, MOD_DEF0
+ * muxed on a single GPIO).
+ *
+ * Copyright (c) 2025 Jonas Jelonek <jelonek.jonas@gmail.com>
+ */
+
+#include <linux/gpio/consumer.h>
+#include <linux/gpio/driver.h>
+#include <linux/mod_devicetable.h>
+#include <linux/mutex.h>
+#include <linux/mux/consumer.h>
+#include <linux/mux/driver.h>
+#include <linux/platform_device.h>
+
+
+struct gpio_split_gpio {
+	unsigned int mux_state;
+};
+
+struct gpio_split {
+	struct gpio_chip gc;
+	struct mux_control *mux;
+	struct device *dev;
+
+	struct mutex lock;
+
+	struct gpio_desc *shared_gpio;
+	/* dynamically sized, must be last */
+	struct gpio_split_gpio gpios[];
+};
+
+DEFINE_GUARD(gpio_split, struct gpio_split *, mutex_lock(&_T->lock), mutex_unlock(&_T->lock))
+
+static int gpio_split_gpio_get(struct gpio_chip *gc, unsigned int offset)
+{
+	struct gpio_split *gs = (struct gpio_split *)gpiochip_get_data(gc);
+	struct gpio_split_gpio *gs_gpio;
+	int ret;
+
+	if (offset > gc->ngpio)
+		return -EINVAL;
+
+	guard(gpio_split)(gs);
+
+	gs_gpio = &gs->gpios[offset];
+	ret = mux_control_select(gs->mux, gs_gpio->mux_state);
+	if (ret < 0)
+		return ret;
+
+	ret = gpiod_get_raw_value_cansleep(gs->shared_gpio);
+	mux_control_deselect(gs->mux);
+	return ret;
+}
+
+static void gpio_split_gpio_set(struct gpio_chip *gc, unsigned int offset,
+				int value)
+{
+	struct gpio_split *gs = (struct gpio_split *)gpiochip_get_data(gc);
+	struct gpio_split_gpio *gs_gpio;
+	int ret;
+
+	if (offset > gc->ngpio)
+		return;
+
+	guard(gpio_split)(gs);
+
+	gs_gpio = &gs->gpios[offset];
+	ret = mux_control_select(gs->mux, gs_gpio->mux_state);
+	if (ret < 0)
+		return;
+
+	gpiod_set_raw_value_cansleep(gs->shared_gpio, value);
+	mux_control_deselect(gs->mux);
+}
+
+static int gpio_split_gpio_get_direction(struct gpio_chip *gc,
+					 unsigned int offset)
+{
+	struct gpio_split *gs = (struct gpio_split *)gpiochip_get_data(gc);
+
+	if (offset > gc->ngpio)
+		return -EINVAL;
+
+	guard(gpio_split)(gs);
+
+	return gpiod_get_direction(gs->shared_gpio);
+}
+
+static int gpio_split_gpio_direction_input(struct gpio_chip *gc,
+					   unsigned int offset)
+{
+	struct gpio_split *gs = (struct gpio_split *)gpiochip_get_data(gc);
+
+	if (offset > gc->ngpio)
+		return -EINVAL;
+
+	guard(gpio_split)(gs);
+
+	return gpiod_direction_input(gs->shared_gpio);
+}
+
+static int gpio_split_gpio_direction_output(struct gpio_chip *gc,
+					    unsigned int offset, int value)
+{
+	struct gpio_split *gs = (struct gpio_split *)gpiochip_get_data(gc);
+
+	if (offset > gc->ngpio)
+		return -EINVAL;
+
+	guard(gpio_split)(gs);
+
+	return gpiod_direction_output_raw(gs->shared_gpio, value);
+}
+
+static const struct of_device_id gpio_split_of_match[] = {
+	{ .compatible = "gpio-split" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, gpio_split_of_match);
+
+static int gpio_split_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct gpio_split *gs;
+	struct fwnode_handle *child;
+	unsigned int ngpio, size, i;
+	int ret;
+
+	ngpio = device_get_child_node_count(dev);
+	size = sizeof(*gs) + (sizeof(struct gpio_split_gpio) * ngpio);
+
+	gs = devm_kzalloc(dev, size, GFP_KERNEL);
+	if (!gs)
+		return -ENOMEM;
+
+	mutex_init(&gs->lock);
+
+	gs->dev = dev;
+	gs->gc.base = -1;
+	gs->gc.can_sleep = true;
+	gs->gc.fwnode = dev_fwnode(dev);
+	gs->gc.label = "gpio-split";
+	gs->gc.ngpio = ngpio;
+	gs->gc.owner = THIS_MODULE;
+	gs->gc.parent = dev;
+
+	gs->gc.get = gpio_split_gpio_get;
+	gs->gc.set = gpio_split_gpio_set;
+	gs->gc.get_direction = gpio_split_gpio_get_direction;
+	gs->gc.direction_input = gpio_split_gpio_direction_input;
+	gs->gc.direction_output = gpio_split_gpio_direction_output;
+
+	gs->mux = devm_mux_control_get(dev, NULL);
+	if (IS_ERR(gs->mux)) {
+		if (PTR_ERR(gs->mux) == -EPROBE_DEFER) {
+			dev_err(dev, "mux-controller not ready, deferring probe\n");
+			return -EPROBE_DEFER;
+		}
+
+		dev_err(dev, "could not get mux-controller\n");
+		return PTR_ERR(gs->mux);
+	}
+
+	gs->shared_gpio = devm_gpiod_get(dev, "shared", GPIOD_ASIS);
+	if (IS_ERR(gs->shared_gpio)) {
+		dev_err(dev, "could not get shared-gpio\n");
+		return PTR_ERR(gs->shared_gpio);
+	}
+
+	i = 0;
+	device_for_each_child_node(dev, child) {
+		struct gpio_split_gpio *gpio = &gs->gpios[i];
+		u32 mux_state;
+
+		ret = fwnode_property_read_u32(child, "mux-state", &mux_state);
+		if (ret) {
+			dev_err(dev, "gpio %u: failed to read mux-state\n", i);
+			return ret;
+		}
+
+		gpio->mux_state = (unsigned int)mux_state;
+		i++;
+	}
+
+	ret = devm_gpiochip_add_data(dev, &gs->gc, gs);
+	if (ret) {
+		dev_err(dev, "failed to add gpiochip: %d\n", ret);
+		return ret;
+	}
+
+	dev_info(dev, "providing %u virtual GPIOs for real GPIO %u\n", i,
+		 desc_to_gpio(gs->shared_gpio));
+	return 0;
+}
+
+static struct platform_driver gpio_split_driver = {
+	.driver = {
+		.name = "gpio-split",
+		.of_match_table = gpio_split_of_match,
+	},
+	.probe = gpio_split_probe,
+};
+module_platform_driver(gpio_split_driver);
+
+MODULE_AUTHOR("Jonas Jelonek <jelonek.jonas@gmail.com>");
+MODULE_DESCRIPTION("GPIO split driver");
+MODULE_LICENSE("GPL");
-- 
2.48.1

Re: [RFC PATCH v1 2/2] gpio: add gpio-split driver

[Linus Walleij]

Hi Jonas,

thanks for your patch!

overall I like the idea and I think we definitely need
something like this.

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

> Add a new driver which allows to split a physical GPIO into multiple
> virtual GPIOs by using a multiplexer.
>
> For now, this doesn't support advanced features like IRQs, just normal
> IN and OUT functionality of GPIOs.
>
> This can help in various usecases. One practical case is the special
> hardware design of the Realtek-based XS1930-10 switch from Zyxel. It
> features two SFP+ ports/cages whose signals are wired to directly to the
> switch SoC. Although Realtek SoCs are short on GPIOs, there are usually
> enough the fit the SFP signals without any hacks.
>
> However, Zyxel did some weird design and connected RX_LOS, MOD_ABS and
> TX_FAULT of one SFP cage onto a single GPIO line controlled by a
> multiplexer (the same for the other SFP cage). The single multiplexer
> controls the lines for both SFP and depending on the state, the
> designated 'signal GPIO lines' are connected to one of the three SFP
> signals.
>
> Because the SFP core/driver doesn't support multiplexer but needs single
> GPIOs for each of the signals, this driver fills the gap between both.
> It registers a gpio_chip, provides multiple virtual GPIOs and sets the
> backing multiplexer accordingly.
>
> Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>

This can be made easier these days, reusing the
forwarder library. I think! Check if I'm right.
Make sure you use kernel v6.18-rc1 as a
baseline for your next patch iteration.

select GPIO_AGGREGATOR

#include <linux/gpio/forwarder.h>

Look into this driver for an example of forwarding
GPIO lines:
drivers/pinctrl/pinctrl-upboard.c

See
commit dca2f73cf19fedd7bc38fa6a0eb50fea63cd0214

Now that is a pin controller so it contains a lot of
irrelevant stuff. Focus on the forwarding part.

This part is maybe the most interesting:

        fwd = devm_gpiochip_fwd_alloc(dev, pctrl->pctrl_data->ngpio);

Here ngpio will be 1 for your usecase.

        if (IS_ERR(fwd))
                return dev_err_probe(dev, PTR_ERR(fwd), "Failed to
allocate the gpiochip forwarder\n");

        chip = gpiochip_fwd_get_gpiochip(fwd);
        chip->request = upboard_gpio_request;
        chip->free = upboard_gpio_free;
        chip->get_direction = upboard_gpio_get_direction;
        chip->direction_output = upboard_gpio_direction_output;
        chip->direction_input = upboard_gpio_direction_input;

        ret = gpiochip_fwd_register(fwd, pctrl);
        if (ret)
                return dev_err_probe(dev, ret, "Failed to register the
gpiochip forwarder\n");

As you can see you can override request/free/get_direction etc.

In this case you probably don't want to override these functions,
but instead override chip->get and chip->set so that these set
the mux (and delay a bit?) before reading/writing the line.

->get_multiple and ->set_multiple seems hard to implement
and should probably be overridden with functions returning
an error.

> +++ b/drivers/gpio/gpio-split.c

As mentioned I would call this gpio-line-mux.c

Yours,
Linus Walleij

Re: [RFC PATCH v1 2/2] gpio: add gpio-split driver

[Jonas Jelonek]

Hi Linus,

On 14.10.25 10:37, Linus Walleij wrote:
> This can be made easier these days, reusing the
> forwarder library. I think! Check if I'm right.

I think this doesn't really simplify things her. As far as I can see the
GPIO forwarder is more targeted toward 1-to-1 scenarios, requiring some
(or even more?) "hackery" to fit to my 1-to-many.

> This part is maybe the most interesting:
>
>         fwd = devm_gpiochip_fwd_alloc(dev, pctrl->pctrl_data->ngpio);
>
> Here ngpio will be 1 for your usecase.

Giving ngpio=1 here makes the gpiochip only provide a single gpio. This then
needs to be the number of GPIOs defined in the DT (number of child nodes).
But in this case, the internal 'descs' is allocated accordingly and there's a
1-to-1-mapping between the external offset and internal offset. To solve this
I would have to add the same descriptor for the shared gpio multiple times.
Not sure if this is a good idea.

>> +++ b/drivers/gpio/gpio-split.c
> As mentioned I would call this gpio-line-mux.c

Sure, will be changed.

> Yours,
> Linus Walleij

Best,
Jonas

Re: [RFC PATCH v1 2/2] gpio: add gpio-split driver

[Linus Walleij]

On Thu, Oct 16, 2025 at 5:37 PM Jonas Jelonek <jelonek.jonas@gmail.com> wrote:

> I think this doesn't really simplify things her. As far as I can see the
> GPIO forwarder is more targeted toward 1-to-1 scenarios, requiring some
> (or even more?) "hackery" to fit to my 1-to-many.

I see hm OK you worked on it so you know better what
will be most elegant here, let's see what the others say.

I'm curious what v2 will look like!

Yours,
Linus Walleij