Re: GPIO static allocation warning with v6.2-rcX

[Bartosz Golaszewski <brgl@xxxxxxxx>]

On Mon, Jan 30, 2023 at 5:48 PM Uwe Kleine-König
<u.kleine-koenig@xxxxxxxxxxxxxx> wrote:
>
> On Mon, Jan 30, 2023 at 11:19:11AM +0100, Linus Walleij wrote:
> > On Sun, Jan 29, 2023 at 7:33 PM Robert Schwebel
> > <r.schwebel@xxxxxxxxxxxxxx> wrote:
> >
> > > While this could also be done with a daemon offering a dbus api, this
> > > would be significantly more complex. In a critical environment, one
> > > needs to make sure that the daemon process never fails, otherwhise the
> > > power of the DuT would maybe be in a random state. Then of course one
> > > can add a watchdog, but with the current sysfs interface it's really
> > > simple. Of course that would also work if the new interface would offer
> > > a "keep this line as it is" feature, but adding a dbus daemon just for
> > > keeping the state of a pin sounds overcomplex when the kernel could also
> > > provide that functionality.
> >
> > One issue we face as developers is scaleability. Things that
> > seem straight forward on a single board computer in a lab get
> > really complex in a big system with man GPIO chips.
>
> This is the point where the discussion took a wrong turn.
>
> Yes, there is awareness that the sysfs API has a downside (here: on some
> platforms the number allocation is not stable).
>
> But the problem here is that the alternative (i.e. using the newer
> devctrl API) also has a downside that makes it unsuitable (or overly
> complex) to use for some workflows.
>
> Just an idea: Wouldn't a nice solution be to make it possible to opt-out
> of the reset to the safe state after use?
>

This is a misconception though. There IS NO safe-state. This is
entirely driver-dependent. When you release a line, its state is no
longer defined by design because it SHOULD be driven by the user of
the line for AS LONG as they keep it.

Sysfs interface is in fact just an in-kernel user and in that regard
is no different from a user-space dbus daemon or interactive gpioset
except for existing in kernel-space. It's no more immune to code bugs
either so I find the argument about the daemon crashing invalid. Your
program setting sysfs entries may crash leaving the line inaccessible
to another valid user. Sysfs code may break - especially as it's no
longer maintained as actively as before. When you unexport a line in
sysfs - its state is no more defined than when releasing it using the
character device.

The so-called safe-state is something that apparently comes back every
3 years (according to Rob) for both user- and kernel-space users but
so far nobody has figured out a good way of implementing it. One of
these days...

Bart