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

[Kent Gibson <warthog618@xxxxxxxxx>]

I didn't respond to this earlier, as I considered it best to let the
thread die and not inflame the issue.

Adding Andy as he raised the issue again in another thread.

On Sun, Jan 29, 2023 at 07:33:39PM +0100, Robert Schwebel wrote:
> On Thu, Jan 26, 2023 at 11:49:27AM +0100, Sascha Hauer wrote:
> > What's missing is a way to let a GPIO stay in the current state when I
> > release a GPIO chip. Unlike the new features you listed above this is a
> > feature that the sysfs API offers and that's important for us.
> 

I assume you mean release a line...

The new (cdev) interface provides access control over lines so you can
guarantee that you, and only you, have control over the line.
This is not possible with sysfs.

With cdev, and internally with gpiolib, the state is only guaranteed while
the line has an owner, and when you release line it becomes unowned -
ownership effectively reverts to the GPIO chip driver.
Its state does not become random, it becomes undefined from the
perspective of the former owner.  Neither cdev nor gpiolib change the
line state when the line is released - any changes at that point are a
function of the GPIO chip driver.

(With sysfs, it becomes the owner of exported lines.)

> An example where it is used is labgrid: our test automation controller
> (LXA-TAC) doesn't run any software for controlling power of the device-
> under-test; to switch on a DuT, labgrid does
> 
>   ssh tac echo 1 > /sys/some/path/to/gpio
> 

As can anything else that can access /sys/some/path/to/gpio.
So it is possible for multiple test benches to mess with the DuT power at
the same time.  Using cdev would make that impossible.

cdev providing access control does mean that it is more awkward to use
than sysfs, but to provide a "set and forget" feature akin to sysfs would
undermine that access control and the associated benefits.

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

So it is non-trivial for your test framework to run a process on a
remote host for the duration of a test?
That is a problem.
Seems like something that would be generally useful, and having it run
gpioset for the duration of a test *should* be pretty trivial.

Unlike sysfs, when you request a line with cdev nothing else can come
along and mess with your power switch while your test is using it.
Which seems like something you might want in a critical environment.

Wrt complexity, I would contend that it is actually more work to add
this functionality to the kernel.  The state of GPIO lines when not held
by gpiolib is dependent on the GPIO chip driver, so solving the problem
for all cases would involve extending the GPIO chip driver API and
updating *all* GPIO chip drivers to keep the state of the pin as
requested - even when the line is freed.
Even if this were to happen, it would take significant time and effort,
so it would be more practical to try to find a solution that uses cdev
as it stands.

> Another example that came up on friday when we talked about this is a
> motor for an airplane: It doesn't have only one "safe state" it could
> fall back to if something fails (i.e. daemon disappears). The safe state
> on power-on (with uninitialized external hardware) might be different
> from the one on the ground (motor-off) or while being in the air
> (motor-on). Of course one would probably not build an airplane without
> further safety mechanics, but we have several less-desasterous-but-
> still-very-expensive-in-the-case-of-failure use cases in the field, like
> multi hundret kilowatt motors in agricultural or heavy construction
> machine equipment being switched on/off by a GPIO that cause significant
> loss of material / work on failure.
> 

Agreed - such applications should have external safety mechanics, so
the software safe state is irrelevant.

> I hope those examples help a bit to understand the issues. As Sascha
> said: when the new interface provides the same features sysfs offers
> today, without adding tons of new complexity, increasing the pressure on
> people to move there is perfectly fine. 
> 

Can you elaborate on "adding tons of new complexity"?
You mean that you can't drive GPIOs just by echoing into files?

I don't see any GPIO developers "pressuring" anyone to switch.
The standard process to remove old interfaces is to mark them as
deprecated and provide time for users to migrate to alternatives.
This is exactly what has been done.
The sysfs interface has been deprecated for a very long time (since
2015??).
And the deprecation suggested it was scheduled for removal in 2020.
Exactly how much warning is required for you not to feel "pressured"?

We well understand that there are trade-offs involved in the switch from
sysfs to cdev, and have endeavoured to accomodate sysfs users.
The problem as I see it is sysfs users who continue to insist on feature
parity while not appreciating the associated costs.

Cheers,
Kent.