Re: [PATCH v2 2/2] gpio: gpio-adg1414: New driver

[Nuno Sá <noname.nuno@xxxxxxxxx>]

On Mon, 2025-02-17 at 07:02 +0000, Paller, Kim Seer wrote:
> 
> 
> > -----Original Message-----
> > From: Linus Walleij <linus.walleij@xxxxxxxxxx>
> > Sent: Saturday, February 15, 2025 7:22 AM
> > To: Nuno Sá <noname.nuno@xxxxxxxxx>; Jonathan Cameron
> > <jic23@xxxxxxxxxx>
> > Cc: Paller, Kim Seer <KimSeer.Paller@xxxxxxxxxx>; Bartosz Golaszewski
> > <brgl@xxxxxxxx>; Rob Herring <robh@xxxxxxxxxx>; Krzysztof Kozlowski
> > <krzk+dt@xxxxxxxxxx>; Conor Dooley <conor+dt@xxxxxxxxxx>; linux-
> > gpio@xxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx; linux-
> > kernel@xxxxxxxxxxxxxxx; linux-iio <linux-iio@xxxxxxxxxxxxxxx>
> > Subject: Re: [PATCH v2 2/2] gpio: gpio-adg1414: New driver
> > 
> > [External]
> > 
> > Let's check with Jonathan Cameron (IIO maintainer) on this as well.
> > He might have ideas.
> > 
> > For reference, the datasheet:
> > https://www.analog.com/media/en/technical-documentation/data-
> > sheets/adg1414.pdf
> > 
> > (By the way: add the datasheet to a special Datasheet: tag in the
> > commit please!)
> > 
> > On Fri, Feb 14, 2025 at 2:17 PM Nuno Sá <noname.nuno@xxxxxxxxx> wrote:
> > > On Fri, 2025-02-14 at 00:25 +0100, Linus Walleij wrote:
> > 
> > > > Now, the kernel does not have switch subsystem I think,
> > > > so this is something like a special case, so we might be
> > > > compelled to make an exception, if the users will all be in
> > > 
> > > Exactly, since we could not find anything, the best fit seemed like the
> > > gpio
> > > subsystem. I was the one suggesting it since a new subsystem for a simple
> > device
> > > like this looked excessive. If we had more devices that would fit such a
> > > class
> > > of devices, maybe it would make more sense to start thinking on such a
> > > subsystem?
> > > 
> > > > say userspace and make use of this switch for factory lines
> > > > or similar.
> > > 
> > > Kim should know better again (about usecases) but I would also assume this
> > is
> > > for userspace use.
> > 
> > Actually the GPIO documentation Documentation/driver-api/gpio/using-
> > gpio.rst
> > even talks about this for userspace use cases:
> > 
> > "The userspace ABI is intended for one-off deployments. Examples are
> > prototypes,
> > factory lines, maker community projects, workshop specimen, production
> > tools,
> > industrial automation, PLC-type use cases, door controllers, in short a
> > piece
> > of specialized equipment that is not produced by the numbers, requiring
> > operators to have a deep knowledge of the equipment and knows about the
> > software-hardware interface to be set up. They should not have a natural fit
> > to any existing kernel subsystem and not be a good fit for an operating
> > system,
> > because of not being reusable or abstract enough, or involving a lot of non
> > computer hardware related policy."
> > 
> > If this is the usecase, like controlling an external switch for such things,
> > using the GPIO subsystem might actually be reasonable in my opinion,
> > (even if the DT bindings end up in their own category).
> > 
> > If the switches control stuff related to computer machinery (i.e. integrated
> > into a laptop to switch on/off the fans...) then no. So it depends on how
> > and where it will be used.
> 
> In my case, this is a userspace use case. The ADG1414 was used to control the
> ADMFM2000 Microwave Downconverter device. According to the ADMFM2000
> datasheet, it requires control over 14 digital pins, which can be set high or
> low [1].
> While these pins could be directly controlled using GPIO, the evaluation board
> for
> the ADMFM2000 is designed to use the ADG1414 switch for this purpose [2].
> ADG1414 is an SPI controlled switch that allows switching of these digital
> control lines.
> 

AFAICT the mux subsystem does not have any userspace so it would already not fit
the above usecase. We could add a simple setter sysfs interface if Peter thinks
this belongs to the mux subsystem...

Let's see what Peter has to say about this.

What about misc devices? I mean, if there's no agreement... 

- Nuno Sá