linux-kernel - Re: [PATCH 0/2] mux: gpio: add support for ADG1712 quad SPST switch

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: <0bda62bf-c0f1-49c8-2f86-8128b5c92a0c@axentia.se>
Date: Fri, 21 Nov 2025 23:54:00 +0100
From: Peter Rosin <peda@...ntia.se>
To: Antoniu Miclaus <antoniu.miclaus@...log.com>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Linus Walleij
 <linus.walleij@...aro.org>, Bartosz Golaszewski <brgl@...ev.pl>,
 Srinivas Kandagatla <srini@...nel.org>, David Lechner
 <dlechner@...libre.com>, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-gpio@...r.kernel.org
Subject: Re: [PATCH 0/2] mux: gpio: add support for ADG1712 quad SPST switch

Hi!

2025-11-21 at 12:57, Antoniu Miclaus wrote:
> [You don't often get email from antoniu.miclaus@...log.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> This series adds support for the Analog Devices ADG1712 quad single-pole/
> single-throw (SPST) switch to the existing GPIO multiplexer driver.
> 
> The ADG1712 contains four independent switches, each controlled by a
> dedicated GPIO pin. Unlike traditional multiplexers that use GPIOs as
> binary-encoded selectors, the ADG1712 treats each GPIO as a direct switch
> controller.
> 
> However, the existing gpio-mux driver architecture handles this perfectly
> by treating the mux state (0-15) as representing all possible combinations
> of the four independent switches. The existing mux_gpio_set() function uses
> gpiod_multi_set_value_cansleep() which treats the state as a bitmap,
> setting each GPIO according to the corresponding bit position.
> 
> For example:
> - State 0 (0000): All switches OFF
> - State 5 (0101): SW1=ON, SW2=OFF, SW3=ON, SW4=OFF
> - State 15 (1111): All switches ON
> 
> This approach allows the ADG1712 to leverage the existing mux framework
> for switch control while reusing all existing gpio-mux infrastructure
> without any code changes beyond adding the compatible string.

No, this is just wrong. If you were to treat the four SPST switches
as some kind of a edge case muxes, they would need to be represented
as four *independent* mux controllers. What you have done when you
tied the four gpios together like this would be appropriate for
a single SP16T mux. Which is not exactly what you have...

So, this series abuses the mux design and is therefore rejected.
Sorry.

Side note, representing the four switches as muxes works perfectly
w/o adding an explicit compatible. Just use four nodes compatible
with "gpio-mux" with a single gpio each. But of course, this foils
the synchronized update property, which I suspect is important, but
that's not a problem the mux subsystem can be expected to solve.

Cheers,
Peter