linux-kernel - Re: [PATCH v4 0/2] mux: gpio-mux: add enable GPIO support

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] [day] [month] [year] [list]

Message-ID: <CAD++jLkvqkHKRnrCCFc=mRBxtt7=fZHH+nDjuJwp5YayCC7z4g@mail.gmail.com>
Date: Wed, 21 Jan 2026 13:37:18 +0100
From: Linus Walleij <linusw@...nel.org>
To: "Miclaus, Antoniu" <Antoniu.Miclaus@...log.com>
Cc: Peter Rosin <peda@...ntia.se>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Srinivas Kandagatla <srini@...nel.org>, Johan Hovold <johan+linaro@...nel.org>, 
	David Lechner <dlechner@...libre.com>, 
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 0/2] mux: gpio-mux: add enable GPIO support

On Tue, Jan 20, 2026 at 3:28 PM Miclaus, Antoniu
<Antoniu.Miclaus@...log.com> wrote:

> > From: Linus Walleij <linusw@...nel.org>
> > Sent: Monday, January 19, 2026 1:19 AM
> > To: Miclaus, Antoniu <Antoniu.Miclaus@...log.com>
> > Cc: Peter Rosin <peda@...ntia.se>; Rob Herring <robh@...nel.org>; Krzysztof
> > Kozlowski <krzk+dt@...nel.org>; Conor Dooley <conor+dt@...nel.org>;
> > Srinivas Kandagatla <srini@...nel.org>; Johan Hovold
> > <johan+linaro@...nel.org>; David Lechner <dlechner@...libre.com>;
> > devicetree@...r.kernel.org; linux-kernel@...r.kernel.org
> > Subject: Re: [PATCH v4 0/2] mux: gpio-mux: add enable GPIO support
> >
> > [External]
> >
> > Hi Antoniu,
> >
> > thanks for your patch!
> >
> > On Fri, Jan 16, 2026 at 4:38 PM Antoniu Miclaus
> > <antoniu.miclaus@...log.com> wrote:
> >
> > > This series adds optional enable GPIO support to the gpio-mux driver.
> > > The enable GPIO allows the multiplexer to be disabled before changing
> > > address lines and re-enabled after, preventing glitches that could
> > > briefly activate unintended channels during transitions.
> > >
> > > This feature is useful for devices like the Analog Devices ADG2404
> > > (4:1 mux) that require enable control for glitch-free operation. The
> > > binding documentation now includes ADG2404 as a supported device with
> > > a dedicated example.
> >
> > Overall the idea is sound!
> >
> > I don't know if "enable" is a good name for this GPIO though,
> > because as I understand it the signal passes through the mux even
> > if it is "disabled"?
> >
> > I would call it "hold" and make it active low if it holds the mux
> > state when this signal is low.
> >
> > hold-gpios = <&gpio 0 GPIO_ACTIVE_LOW>;
> >
> > this will have the intended semantic.
> >
>
> Thanks for the feedback!
>
> Looking at the ADG2404 truth table, "enable" appears
> to be semantically correct:
>
>   EN  A1  A0  S1   S2   S3   S4
>   0   X   X   Off  Off  Off  Off
>   1   0   0   On   Off  Off  Off
>   1   0   1   Off  On   Off  Off
>   1   1   0   Off  Off  On   Off
>   1   1   1   Off  Off  Off  On
>
> When EN=0, all switches are OFF and no signal passes through
> the mux - it's truly disabled. When EN=1, exactly one channel is
> selected based on the address pins A1/A0.

Okay.

Yeah enable-gpios is fine for this thing.

>   The implementation uses this to:
>   - Keep all channels disconnected when idle (EN=0)
>   - Disable during address changes to prevent glitches
>   - Enable to activate the selected channel

I'm a bit sceptic to how it actually works in practice.
You need to specify what the truth table says: all swiches
will be disabled when enable is off, that actually doesn't
guarantee there will be no glitches.

When you disconnect something in a mux it usually enters a
tristate (high-Z) on the output, does it not? It doesn't really
"hold" the signal that was going through.

This means if there is something connected to the outputs
this will definitely see a "glitch" as in the signal being
disabled for a short while when enable is held low.

So the output will occasionally be disabled.

I think what your patch achives is that none of the outputs
will ever be *enabled* by a glitch. But instead you introduce
a mechanism which will randomly *disable* *all* outputs
when the state is changed.

This can have side effects if e.g. one of the lines on the
output is something logic that is actively pulled down, it will
dip to zero.

But I guess that is not a problem with the intended applications,
since the signal going through is analog? That analog
signal will probably be sustained on the output if and only if
there is something like a capacitance there holding whatever
signal was before for a short while, right?

I think this needs a bit of description about how this works
in a practical use case. Also as comment in the code and/or
DT binding.

Yours,
Linus Walleij