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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID:
 <CY4PR03MB3399699BCF110D3E68E0A6479BDEA@CY4PR03MB3399.namprd03.prod.outlook.com>
Date: Wed, 26 Nov 2025 14:44:23 +0000
From: "Miclaus, Antoniu" <Antoniu.Miclaus@...log.com>
To: Peter Rosin <peda@...ntia.se>, 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"
	<devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>,
        "linux-gpio@...r.kernel.org"
	<linux-gpio@...r.kernel.org>
Subject: RE: [PATCH 0/2] mux: gpio: add support for ADG1712 quad SPST switch

Hi Peter,

> -----Original Message-----
> From: Peter Rosin <peda@...ntia.se>
> Sent: Saturday, November 22, 2025 12:54 AM
> To: Miclaus, Antoniu <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
> 
> [External]
> 
> 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://urldefense.com/v3/__https://aka.ms/LearnAboutSenderIdentificatio
> n__;!!A3Ni8CS0y2Y!496DlFUidna4Sqh1tbK2ZFR26RJOQIejUdeLkSt5BuIzZtJ4
> xlzAiFZGcByaa6NZLNbT4B2rkPxtCyNH_Vo$  ]
> >
> > 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.
> 

Thanks for the explanation!

Would it still make sense to have an adi,adg1712.yaml binding, 
(under /mux or /switch) even if it just documents the proper way
to use this chip (four separate gpio-mux nodes)?
I'm thinking from a user perspective - someone with an ADG1712
on their board will search for "adg1712" in the docs and find nothing.
A dedicated binding could just show the correct approach with a
working example for users.

Regards,

> Cheers,
> Peter