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

["Paller, Kim Seer" <KimSeer.Paller@xxxxxxxxxx>]

> -----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.

Then, I have a custom userspace application to access sysfs, which in turn controls the
ADG1414, providing specific functions for the ADMFM2000. Using the GPIO subsystem
to interface with the ADG1414 perhaps a practical way to manage these control
signals.

In my opinion, using the GPIO subsystem for the ADG1414 may be a better option
given the intended use case. However, what do you suggest on how to proceed?

[1] https://www.analog.com/media/en/technical-documentation/data-sheets/admfm2000.pdf
[2] https://www.analog.com/en/resources/evaluation-hardware-and-software/evaluation-boards-kits/eval-admfm2000.html#eb-overview

All the best,
Kim

> 
> Yours,
> Linus Walleij