RE: [PATCH 0/2] mux: gpio: add support for ADG1712 quad SPST switch

[Miclaus, Antoniu]

Hi Peter,

> -----Original Message-----
> From: Peter Rosin <peda@xxxxxxxxxx>
> Sent: Saturday, November 22, 2025 12:54 AM
> To: Miclaus, Antoniu <Antoniu.Miclaus@xxxxxxxxxx>; Rob Herring
> <robh@xxxxxxxxxx>; Krzysztof Kozlowski <krzk+dt@xxxxxxxxxx>; Conor Dooley
> <conor+dt@xxxxxxxxxx>; Linus Walleij <linus.walleij@xxxxxxxxxx>; Bartosz
> Golaszewski <brgl@xxxxxxxx>; Srinivas Kandagatla <srini@xxxxxxxxxx>; David
> Lechner <dlechner@xxxxxxxxxxxx>; devicetree@xxxxxxxxxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx; linux-gpio@xxxxxxxxxxxxxxx
> 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@xxxxxxxxxx. 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