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

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

[Linus Walleij]

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@gmail.com> 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.

Yours,
Linus Walleij

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

[Jonathan Cameron]

On Sat, 15 Feb 2025 00:22:20 +0100
Linus Walleij <linus.walleij@linaro.org> wrote:

> 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@gmail.com> 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.

Maybe, treat them as a weird mux? A switch is similar to a mux with only
one connected path.  +CC Peter. 

Jonathan

> 
> Yours,
> Linus Walleij

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

[Paller, Kim Seer]

> -----Original Message-----
> From: Linus Walleij <linus.walleij@linaro.org>
> Sent: Saturday, February 15, 2025 7:22 AM
> To: Nuno Sá <noname.nuno@gmail.com>; Jonathan Cameron
> <jic23@kernel.org>
> Cc: Paller, Kim Seer <KimSeer.Paller@analog.com>; Bartosz Golaszewski
> <brgl@bgdev.pl>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; linux-
> gpio@vger.kernel.org; devicetree@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-iio <linux-iio@vger.kernel.org>
> 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@gmail.com> 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

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

[Nuno Sá]

On Mon, 2025-02-17 at 07:02 +0000, Paller, Kim Seer wrote:
> 
> 
> > -----Original Message-----
> > From: Linus Walleij <linus.walleij@linaro.org>
> > Sent: Saturday, February 15, 2025 7:22 AM
> > To: Nuno Sá <noname.nuno@gmail.com>; Jonathan Cameron
> > <jic23@kernel.org>
> > Cc: Paller, Kim Seer <KimSeer.Paller@analog.com>; Bartosz Golaszewski
> > <brgl@bgdev.pl>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
> > <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; linux-
> > gpio@vger.kernel.org; devicetree@vger.kernel.org; linux-
> > kernel@vger.kernel.org; linux-iio <linux-iio@vger.kernel.org>
> > 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@gmail.com> 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á

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

[Linus Walleij]

On Mon, Feb 17, 2025 at 8:02 AM Paller, Kim Seer
<KimSeer.Paller@analog.com> wrote:

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

I think it's best to proceed with a GPIO driver unless someone has
better ideas.

Address my comments on the regmap use please!

Yours,
Linus Walleij