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

[Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>]

On Mon, Jan 30, 2023 at 04:01:49PM +0100, Linus Walleij wrote:
> On Mon, Jan 30, 2023 at 12:02 PM Marco Felsch <m.felsch@xxxxxxxxxxxxxx> wrote:
> > On 23-01-30, 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.

Kernel provides it with a cost of a lot of downsides. That's why we moved to
character device approach which is already complex enough. And yeah, the best
what we can do now to support persistent states is to run a daemon.

This also solves the potential security issue (wrong process to access GPIO)
with legacy interface.

No doubt we need to kill sysfs GPIO ABI.

> > > 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.
> >
> > Does it? At least the drive I listed (e.g. the imx gpio driver) uses
> > aliases to make it reliable.
> 
> I'm not sure that is the intended use of the aliases in device tree.
> (Rob can maybe answer this.)
> 
> Besides, the problem exist also in ACPI (think every x86
> laptop) which does not have anything like the alias mechanism
> AFAIK. If it does, Andy will tell us.

We never rely on the pure numbers on ACPI based platforms. Yeah, we have couple
of drivers contradict this, but because of wrong numbers in the ACPI tables
(BIOS bugs) which should have not happened to begin with.

And yes, we don't have aliases because we don't need them. You can always
access GPIO pins based on the naming of the controller + relative number of
line on it. I do not understand why you chose aliases approach instead of
making your scripts more robust based on the other information available.

-- 
With Best Regards,
Andy Shevchenko