Re: Assign line names at runtime

[Bartosz Golaszewski <brgl@xxxxxxxx>]

On Fri, Jan 12, 2024 at 1:36 AM Kent Gibson <warthog618@xxxxxxxxx> wrote:
>
> On Thu, Jan 11, 2024 at 04:52:24PM +0000, Westermann, Oliver wrote:
> > Hey and thanks for your responses, those are actually quite insightful.
> >
> > What I read from that is that changing line names really has a lot of
> > implications.
> >
>
> After sleeping on it, I don't think line renaming is actually such a big issue.
>
> Firstly, hot plugging means the line namespace is never going to be
> static, even if I was tacitly assuming it was.  Turns out I don't think
> that matters as much as I thought anyway.  We just need to make sure the
> user is aware of it as well.
>
> The analogy I would use is files in a filesystem, where the chip
> corresponds to a directory and the line a file.  We aren't terribly
> concerned that a file may be renamed while we do a find, or while
> opening or using a file, so it should be the same for a line.
>
> We rename a file through the directory, so it makes sense to rename the
> line through the chip, and not require the line to be requested.
> So we would add a new ioctl on the chip to perform the rename.
> Could make that more general in case we ever add something else to line
> info that isn't controlled by requesting the line, but I'm note sure the
> additional complexity would be worth it, given how unlikely that is.
> But I digress...
>
> We don't inform a user with an open file that it may have been renamed
> while open, so neither would we with the line. If it is an issue for you
> then you can add a watch on the line info, similar to using inotify
> on the filesystem.
>
> The point the analogy breaks down a bit is that we allow duplicate names,
> (I don't think anyone really wants that feature, but historically it has
> been allowed so we're stuck with it.) but I don't think that is of any
> consequence to this discussion.
>

This analogy is great and all but there's one issue with it - we're
not dealing with a filesystem that everyone can modify. We have more
or less agreed so far that we allow multiple readers of GPIO
information but whenever there's any setting done, one needs to
request the line for exclusive usage. Now we'd break that logic by
allowing all users to arbitrarily rename GPIO lines and I don't like
this.

> If we did want to provide a consistent view of the line namespace, that
> might be something the GPIO daemon provides. (conveniently handballing
> the problem to Bart ;-)
>
> > Kent Gibson wrote:
> > > Alternatively, are named lines the right solution to your problem?
> > > Is it important to you that the lines are correctly named, or are you
> > > just using the name for the chip/offset lookup?
> >
> > We would really like to use named lines as they are really convinient, but
> > your question actually made me rethink my initial question. We do actually
> > not want to change line names, they are constant throughout the runtime of
> > a device.
> >
> > > If the latter perhaps roll your own pinout lookup based on the platform configuration?
> >
> > The truth might lay in between: We would prefer to use existing features and
> > standard interfaces instead of rolling out our own layer. But maybe it's
> > just the initial naming that we want to move. A better solution might be to
> > add another option to define and probe the GPIO driver at runtime: Instead
> > of being required to set all information in the dtb (and therefore from a
> > very low level), we might trigger the probing through modprobe and provide
> > the GPIO line names from userspace. I'm not sure if such an option exists
> > currently?
> >
>
> That sounds like the job of the udev rules that Bart suggested - once we have
> the ability to rename lines from userspace.
>

It would make sense if we could get a udev event about the device
being created, pass device properties - in this case gpio-line-names -
to the kernel for this device and then get it bound to the driver. I
don't think it's possible but I need to look deeper.

Bartosz

> > Best regards and sorry for the quoting style, our mailservers mess with your
> > mails.
> >
>
> No problem with your quoting style - that looks fine to me - it was the lack
> of line wrapping that was the issue. And your response isn't tied into
> the email thread either, which is a bit unfortunate.
>
> Oh, and it would be handy to prefix libgpiod specific questions with
> [libgpiod], though in this case it has rapidly moved into kernel space
> anyway, so no biggy - just for future reference.
>
> Cheers,
> Kent.