public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: "Nuno Sá" <noname.nuno@gmail.com>,
	"Kim Seer Paller" <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>,
	"Peter Rosin" <peda@axentia.se>
Subject: Re: [PATCH v2 2/2] gpio: gpio-adg1414: New driver
Date: Sun, 16 Feb 2025 14:30:52 +0000	[thread overview]
Message-ID: <20250216143052.6f21ace0@jic23-huawei> (raw)
In-Reply-To: <CACRpkda+CDRMYKmjw7kewenkteLhPYb040E4B=ZG6pgdy=65pg@mail.gmail.com>

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


  reply	other threads:[~2025-02-16 14:31 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-13 13:15 [PATCH v2 0/2] Add support for ADG1414 Serially-Controlled Octal SPST Switches Kim Seer Paller
2025-02-13 13:15 ` [PATCH v2 1/2] dt-bindings: gpio: add adg1414 Kim Seer Paller
2025-02-13 16:11   ` kernel test robot
2025-02-13 18:16   ` Krzysztof Kozlowski
2025-02-14 10:42     ` Linus Walleij
2025-02-13 13:15 ` [PATCH v2 2/2] gpio: gpio-adg1414: New driver Kim Seer Paller
2025-02-13 23:25   ` Linus Walleij
2025-02-14 13:17     ` Nuno Sá
2025-02-14 23:22       ` Linus Walleij
2025-02-16 14:30         ` Jonathan Cameron [this message]
2025-02-17  7:02         ` Paller, Kim Seer
2025-02-17  9:32           ` Nuno Sá
2025-02-27  0:33           ` Linus Walleij
2025-02-15  1:12   ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250216143052.6f21ace0@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=brgl@bgdev.pl \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=kimseer.paller@analog.com \
    --cc=krzk+dt@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=noname.nuno@gmail.com \
    --cc=peda@axentia.se \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox