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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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






[Index of Archives]     [Linux SPI]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux