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

[Rob Herring <robh+dt@xxxxxxxxxx>]

On Mon, Jan 30, 2023 at 9:02 AM Linus Walleij <linus.walleij@xxxxxxxxxx> 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.
> > >
> > > 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.)

The kernel community's position on stable device numbers for userspace
is quite clear.

That is how aliases get used by the kernel though. IMO, they should be
limited to a documented set of alias names, and GPIO is not one of
them. We replaced the whole GPIO sysfs API for this reason (among
others).

IIRC, i.MX is one of the worst abusers with aliases for everything,
most of which should be removed.

Rob