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

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

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.

One of the big dangers of the sysfs ABI is that it is dependent on
probe order which the kernel sadly does not really guarantee.

It's a bit like /dev/sda /dev/sdb after you boot up a system with
two USB drives, certainly you know which one is sda and sdb
if you plug them in by hand, but if you just boot the system with
both in, what is the kernel expected to do, and what is expected
to happen? What happens in practice is first come first serve...

This means a script can work for years, and then some random
day a PCI device is sleepy and comes after some other device,
and the numbers of all GPIOs are shuffled.

However, if you feel safe about that, for example if there is only
one GPIO chip on the entire system so there will only ever be
gpiochip0, what do you think about my debugfs proposal?

The below is cut and paste from the drivers/gpio/TODO file:

-------------------------------
Debugfs in place of sysfs

The old sysfs code that enables simple uses of GPIOs from the
command line is still popular despite the existence of the proper
character device. The reason is that it is simple to use on
root filesystems where you only have a minimal set of tools such
as "cat", "echo" etc.

The old sysfs still need to be strongly deprecated and removed
as it relies on the global GPIO numberspace that assume a strict
order of global GPIO numbers that do not change between boots
and is independent of probe order.

To solve this and provide an ABI that people can use for hacks
and development, implement a debugfs interface to manipulate
GPIO lines that can do everything that sysfs can do today: one
directory per gpiochip and one file entry per line:

/sys/kernel/debug/gpiochip/gpiochip0
/sys/kernel/debug/gpiochip/gpiochip0/gpio0
/sys/kernel/debug/gpiochip/gpiochip0/gpio1
/sys/kernel/debug/gpiochip/gpiochip0/gpio2
/sys/kernel/debug/gpiochip/gpiochip0/gpio3
...
/sys/kernel/debug/gpiochip/gpiochip1
/sys/kernel/debug/gpiochip/gpiochip1/gpio0
/sys/kernel/debug/gpiochip/gpiochip1/gpio1
...

The exact files and design of the debugfs interface can be
discussed but the idea is to provide a low-level access point
for debugging and hacking and to expose all lines without the
need of any exporting. Also provide ample ammunition to shoot
oneself in the foot, because this is debugfs after all.
-------------------------------

Yours,
Linus Walleij