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

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

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.

That should make it possible to use my suggested debugfs facility
that provide the same, but does not use the global numberspace.

People who don't care about the complexity involved with the character
device certainly will not care about the downsides of using debugfs in
production either. (Such as interfering with any chardev users...)

> 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?

As Bartosz says there is no reset to any safe state, whatever that
would be. The state is kept in hardware just like with sysfs.

You can even set up the state from sysfs and then read it back
from the character device or vice versa, after freeing each
hogs resources.

It's really just the .get_direction() and .get() callbacks on the
gpio_chip that read the state, .set_direction_input|output()
and .set() sets it, like they always did.

Consider the example too tools/gpio/gpio-hammer.c
that I wrote. It reads the initial line values of the GPIO lines
(from hardware) and then start to invert them. It doesn't start
from any specific state?

Yours,
Linus Walleij