RFC: New switch subsystem for analog/RF switch devices

[Miclaus, Antoniu]

Hi Greg, Linus,  

Thanks a lot for the feedback!

Added the public mailing list + kept most of the info from the private thread.

I looked at the existing IIO drivers. Modeling each switch channel as
an IIO output channel with IIO_CHAN_INFO_ENABLE for on/off control
might fit.

I'm thinking about a prototype for adg1712 driver under drivers/iio/signal-switch/.
Userspace sees:
  out_<channel_type>0_en
  out_<channel_type>1_en
  out_<channel_type>2_en
  out_<channel_type>3_en

SPI devices like the ADGS6414D would be a separate
driver in the same directory, same channel model, different control interface.

Jonathan - does this fit within IIO?
Looking forward to your feedback.

Best regards,
Antoniu

  On Wed, Feb 18, 2026 at 02:18 PM +0200, Greg KH wrote:
  > On Wed, Feb 18, 2026 at 09:38:12AM +0100, Linus Walleij wrote:
  > > Hi Antoniu,
  > >
  > > [CC Jon Cameron]
  > >
  > > in general it is probably better to send this question to a wider audience.
  >
  > Ick, I didn't realize this wasn't on a public mailing list, which is
  > where it should be, and cc: everyone involved.  Let's start it over in
  > public please.
  >
  > > Given that this is an analog device, dealing with analog signals, it has
  > > IIO written all over it. IIO already deals with ADC/DAC, multiplexer
  > > (check it out drivers/iio/multiplexer) and signal (frequency) generators
  > > (drivers/iio/frequency).
  > >
  > > I think it belongs in drivers/iio/signal-switch or something.
  > >
  > > IIO already has an orderly userspace ABI that might not be lightweight
  > > but it looks like it does for a good reason: people use it for complex
  > > signal routing in things I don't even understand such as GNU Radio
  > > SDRs.
  > >
  > > Give it a thought.
  >
  > That sounds reasonable to me.
  >
  > thanks,
  >
  > greg k-h
  >
  > > Yours,
  > > Linus Walleij
  > >
  > > On Fri, Feb 13, 2026 at 4:51 PM Miclaus, Antoniu
  > > <Antoniu.Miclaus@xxxxxxxxxx> wrote:
  > > >
  > > > Hi Greg,
  > > >
  > > > I would like to propose a new switch subsystem under drivers/switch/
  > > > for analog/RF switch devices and would appreciate your feedback.
  > > >
  > > > I previously attempted to upstream the ADG1712 (a quad SPST analog
  > > > switch) through both the GPIO and MUX subsystems, and the feedback
  > > > highlighted a fundamental mismatch:
  > > >
  > > > - Bartosz Golaszewski noted it's a GPIO consumer, not provider, and
  > > >   questioned whether it belongs under drivers/gpio/ at all.
  > > >   https://lore.kernel.org/all/20251117091427.3624-1-antoniu.miclaus@xxxxxxxxxx/
  > > >
  > > > - The MUX subsystem assumes mutually exclusive "select one of N"
  > > >   semantics, which doesn't match independent on/off switch channels.
  > > >   https://lore.kernel.org/20251121115750.20119-1-antoniu.miclaus@xxxxxxxxxx
  > > >
  > > > We have a growing family of devices that share this problem: simple
  > > > GPIO-controlled SPST switches (ADG1712), SPI-controlled MEMS switches
  > > > operating DC-24GHz (ADGM3121/ADGM3144), SPI-controlled high-voltage
  > > > octal switches with CRC and daisy-chaining (ADGS6414D) and others to
  > > > be released soon. Control interfaces vary (GPIO, SPI, I2C) but the
  > > > abstraction is the same: independently controllable on/off channels on
  > > > analog signal paths.
  > > >
  > > > The proposed subsystem would provide:
  > > > - A lightweight core with switch_chip/switch_channel abstractions
  > > > - Support for GPIO, SPI, and I2C control backends
  > > > - Sysfs interface for runtime switch control
  > > >
  > > > Does a standalone subsystem make sense here?
  > > >
  > > > Happy to send an RFC patch series if the direction seems reasonable.
  > > >
  > > > Best regards,
  > > > --
  > > > Antoniu Miclăuş

-- 
Antoniu Miclăuş
Senior Engineer, Embedded Software
Software & Security Group

E-mail: antoniu.miclaus@xxxxxxxxxx
Mobile: +40 747 036533