Re: [PATCH v3 2/2] gpio: add gpio-line-mux driver

[Peter Rosin]

Hi!

2025-11-04 at 22:00, Jonas Jelonek wrote:
> Add a new driver which provides a 1-to-many mapping for a single real
> GPIO using a multiplexer. Each virtual GPIO corresponds to a multiplexer
> state which, if set for the multiplexer, connects the real GPIO to the
> corresponding virtual GPIO.
> 
> 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

wired directly

> 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.
> 
> Due to several practical issues, this is input-only and doesn't support
> IRQs.
> 
> Signed-off-by: Jonas Jelonek <jelonek.jonas@xxxxxxxxx>

*snip*

> diff --git a/drivers/gpio/gpio-line-mux.c b/drivers/gpio/gpio-line-mux.c
> new file mode 100644
> index 000000000000..3a9fe899c041
> --- /dev/null
> +++ b/drivers/gpio/gpio-line-mux.c
> @@ -0,0 +1,137 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * GPIO line mux which acts as virtual gpiochip and provides a 1-to-many
> + * mapping between virtual GPIOs and a real GPIO + multiplexer.
> + *
> + * Copyright (c) 2025 Jonas Jelonek <jelonek.jonas@xxxxxxxxx>
> + */
> +
> +#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>

This mux/driver.h include can be dropped as this driver is not
a mux driver and only uses the consumer side of the mux
interface. Unless I overlook something...

> +#include <linux/platform_device.h>
> +
> +#define MUX_SELECT_DELAY_US	100
> +
> +struct gpio_lmux {
> +	struct gpio_chip gc;
> +	struct mux_control *mux;
> +	struct mutex lock;

This lock can be dropped completely. It is only used where the
pair mux_control_select_delay()/mux_control_deselect() already
provides sufficient locking.

Cheers,
Peter