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.

Patch 1 updates the device tree bindings to support the ADG1712 compatible
string and includes documentation and examples.

Patch 2 adds the minimal driver support by adding the ADG1712 compatible
string to the existing gpio-mux driver.

Antoniu Miclaus (2):
  dt-bindings: mux: gpio-mux: add support for ADG1712
  mux: gpio: add support for ADG1712 quad SPST switch

 .../devicetree/bindings/mux/gpio-mux.yaml     | 24 ++++++++++++++++++-
 drivers/mux/gpio.c                            |  1 +
 2 files changed, 24 insertions(+), 1 deletion(-)

-- 
2.43.0

Hi!

2025-11-21 at 12:57, Antoniu Miclaus wrote:
> [You don't often get email from antoniu.miclaus@analog.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

On 11/21/25 5:57 AM, Antoniu Miclaus wrote:
> 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.
> 

This doesn't sound like a mux at all. It sounds like a solid state
relay.

So it probably doesn't need bindings or a driver. You can just use
the gpio that controls it directly since the output will always
follow the gpio state. (And if the 65 ns delay is an issue, there
is "gpio-delay".)

Using a gpiod array gives the same convenience of being able to
use a value 0-15 to control the state of all 4 at the same time if
needed.