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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20250216143052.6f21ace0@jic23-huawei>
Date: Sun, 16 Feb 2025 14:30:52 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Nuno Sá <noname.nuno@...il.com>, Kim Seer Paller
 <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>, Peter Rosin <peda@...ntia.se>
Subject: Re: [PATCH v2 2/2] gpio: gpio-adg1414: New driver

On Sat, 15 Feb 2025 00:22:20 +0100
Linus Walleij <linus.walleij@...aro.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@...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.

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