All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Dominique Martinet <dominique.martinet@atmark-techno.com>
Cc: "David Lechner" <dlechner@baylibre.com>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>,
	"Jonathan Cameron" <jic23@kernel.org>,
	"Syunya Ohshio" <syunya.ohshio@atmark-techno.com>,
	"Guido Günther" <agx@sigxcpu.org>,
	"Lars-Peter Clausen" <lars@metafoo.de>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] iio: industrialio-core: look for aliases to request device index
Date: Mon, 18 Mar 2024 12:29:53 +0000	[thread overview]
Message-ID: <20240318122953.000013f3@Huawei.com> (raw)
In-Reply-To: <ZfejyEvPIncygKJ9@atmark-techno.com>

On Mon, 18 Mar 2024 11:15:36 +0900
Dominique Martinet <dominique.martinet@atmark-techno.com> wrote:

> David Lechner wrote on Fri, Mar 15, 2024 at 10:53:36AM -0500:
> > How about using udev rules to create symlinks for each device based on
> > the label attribute? No changes to the kernel are needed.  
> 
> Right, it's definitely possible to make symlinks for each "device" -- my
> patch comment links to such an udev script "solution":
> https://git.toradex.com/cgit/meta-toradex-bsp-common.git/tree/recipes-core/udev/files/verdin-imx8mm/toradex-adc.sh?h=kirkstone-6.x.y
> (the script is launched by udev here:
> https://git.toradex.com/cgit/meta-toradex-bsp-common.git/tree/recipes-core/udev/files/verdin-imx8mm/99-toradex.rules
> )
> 
> My conceptual problem with this is that this makes symlinks in /dev to
> files in /sys and it feels like we're crossing boundaries.
> As far as I can tell there is no way for userspace to create arbitrary
> symlinks in /sys, so I think we could have an interface more
> user-friendly by allowing paths to be static for users with multiple
> devices.
> (I guess that's a weak argument given e.g. disks etc will also have an
> unreliable name in /sys in the general case, but simple programs don't
> interact with them in /sys and can use stable links in /dev so my
> expectations here aren't quite the same)
> 
> 
> Ultimately, the problem might run deeper in that we're having userspace
> interact with the device through /sys and not the /dev char dev... As
> far as I could see /dev/iio:deviceX only allows reading buffered values
> and doesn't have any ioctl or other way of reading immediate values as
> is possible in /sys though, so that'd require quite a bit of work to
> duplicate the interface there...

Don't.  The sysfs interface as only control is entirely intentional and
we do not want IOCTL based duplication.

Just addressing this bit as I'm still a bit snowed under to think about this
more generally.




  reply	other threads:[~2024-03-18 12:30 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-28  5:12 [PATCH] iio: industrialio-core: look for aliases to request device index Dominique Martinet
2024-02-28  7:16 ` Krzysztof Kozlowski
2024-02-28  7:31   ` Dominique Martinet
2024-02-28  7:42     ` Krzysztof Kozlowski
2024-02-28  8:11       ` Dominique Martinet
2024-02-28 14:24         ` Jonathan Cameron
2024-02-29  2:59           ` Dominique Martinet
2024-03-15  5:47             ` Dominique Martinet
2024-03-15 15:53               ` David Lechner
2024-03-16 20:17                 ` Andy Shevchenko
2024-03-18  2:15                 ` Dominique Martinet
2024-03-18 12:29                   ` Jonathan Cameron [this message]
2024-03-31 14:20                     ` Jonathan Cameron
2024-04-01  8:18                       ` Dominique Martinet
2024-04-01 16:47                         ` Jonathan Cameron
2024-04-11  5:11                           ` Dominique Martinet
2024-03-18 14:55                   ` David Lechner
2024-03-16 20:14 ` Andy Shevchenko

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=20240318122953.000013f3@Huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=agx@sigxcpu.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=dominique.martinet@atmark-techno.com \
    --cc=jic23@kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=syunya.ohshio@atmark-techno.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.