linux-kernel - Re: [PATCH v4 2/2] gpio: add gpio-line-mux driver

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: <CAMRc=MdQLN5s+MpkLUF2Ggc4vYo30zOXrA=8qkGmXvu7N3JjeA@mail.gmail.com>
Date: Wed, 5 Nov 2025 14:15:50 +0100
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Jonas Jelonek <jelonek.jonas@...il.com>
Cc: Linus Walleij <linus.walleij@...aro.org>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Peter Rosin <peda@...ntia.se>, 
	Geert Uytterhoeven <geert+renesas@...der.be>, linux-gpio@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Thomas Richard <thomas.richard@...tlin.com>
Subject: Re: [PATCH v4 2/2] gpio: add gpio-line-mux driver

On Wed, Nov 5, 2025 at 11:36 AM Jonas Jelonek <jelonek.jonas@...il.com> 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 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.
>
> Due to several practical issues, this is input-only and doesn't support
> IRQs.
>
> Signed-off-by: Jonas Jelonek <jelonek.jonas@...il.com>
> ---

[snip]

> +
> +       glm->mux = devm_mux_control_get(dev, NULL);
> +       if (IS_ERR(glm->mux))
> +               return dev_err_probe(dev, PTR_ERR(glm->mux),
> +                                    "could not get mux controller\n");
> +
> +       glm->shared_gpio = devm_gpiod_get(dev, "shared", GPIOD_ASIS);

Hi Jonas!

This looks good, I'm ready to queue it but I'm afraid the consumer
label "shared" will logically conflict with the work I'm doing on the
shared GPIO support[1] as the shared GPIOs will appear as proxy
devices containing the name "shared". Do you see any problem with
changing the label to "gpio-mux"? I can even change it myself when
applying.

Bartosz

[1] https://lore.kernel.org/all/20251029-gpio-shared-v3-0-71c568acf47c@linaro.org/