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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <bf069d43ed76b68c91130233b264089c3f7b2514.camel@gmail.com>
Date: Mon, 17 Feb 2025 09:32:25 +0000
From: Nuno Sá <noname.nuno@...il.com>
To: "Paller, Kim Seer" <KimSeer.Paller@...log.com>, Linus Walleij
	 <linus.walleij@...aro.org>, Jonathan Cameron <jic23@...nel.org>
Cc: Bartosz Golaszewski <brgl@...ev.pl>, Rob Herring <robh@...nel.org>, 
 Krzysztof Kozlowski	 <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>,  "linux-gpio@...r.kernel.org"	
 <linux-gpio@...r.kernel.org>, "devicetree@...r.kernel.org"	
 <devicetree@...r.kernel.org>, "linux-kernel@...r.kernel.org"	
 <linux-kernel@...r.kernel.org>, linux-iio <linux-iio@...r.kernel.org>,
 Peter Rosin <peda@...ntia.se>
Subject: Re: [PATCH v2 2/2] gpio: gpio-adg1414: New driver

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