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

[Bartosz Golaszewski <brgl@xxxxxxxx>]

On Wed, Jan 25, 2023 at 10:35 AM Sascha Hauer <sha@xxxxxxxxxxxxxx> wrote:
>
> On Mon, Jan 23, 2023 at 03:55:18PM +0100, Bartosz Golaszewski wrote:
> > On Fri, Jan 20, 2023 at 11:46 AM Marco Felsch <m.felsch@xxxxxxxxxxxxxx> wrote:
> > >
> > > Hi all,
> > >
> > > I stumbled over the following warning while testing the new v6.2-rc4 on
> > > a imx8mm-evk:
> > >
> > > [    1.507131] gpio gpiochip0: Static allocation of GPIO base is deprecated, use dynamic allocation.
> > > [    1.517786] gpio gpiochip1: Static allocation of GPIO base is deprecated, use dynamic allocation.
> > > [    1.528273] gpio gpiochip2: Static allocation of GPIO base is deprecated, use dynamic allocation.
> > > [    1.538739] gpio gpiochip3: Static allocation of GPIO base is deprecated, use dynamic allocation.
> > > [    1.549195] gpio gpiochip4: Static allocation of GPIO base is deprecated, use dynamic allocation.
> > >
> > > The warning was introduced by commit [1] but at least the following
> > > drivers are parsing the alias for a gpiochip to use it as base:
> > >  - drivers/gpio/gpio-mxs.c
> > >  - drivers/gpio/gpio-mxc.c
> > >  - drivers/gpio/gpio-clps711x.c
> > >  - drivers/gpio/gpio-mvebu.c
> > >  - drivers/gpio/gpio-rockchip.c
> > >  - drivers/gpio/gpio-vf610.c
> > >  - drivers/gpio/gpio-zynq.c
> > >
> > > According commit [2] it seems valid and correct to me to use the alias
> > > and the user-space may rely on this.
> > >
> > > Now my question is how we can get rid of the warning without breaking
> > > the user-space?
> > >
> > > [1] 502df79b86056 gpiolib: Warn on drivers still using static gpiobase allocation
> > > [2] 7e6086d9e54a1 gpio/mxc: specify gpio base for device tree probe
> > >
> >
> > The warning is there to remind you that static GPIO base numbers have
> > been long deprecated and only user-space programs using sysfs will
> > break if you remove it, everyone else - including user-space programs
> > using libgpiod or scripts using gpio-tools that are part of the
> > project - will be fine.
> >
> > Any chance you can port your user-space programs to libgpiod?
> >
> > The warning doesn't break compatibility so I'm not eager to remove it.
>
> Well it's a warning and sooner or later somebody will come along and
> removes this warning by removing the GPIO controller bases from the dts
> files which in turn will then break things at least for us, but I
> suspect for many other people as well.
>
> You are trying to remove the GPIO sysfs API for many years now without
> success so far, and I doubt that you will succeed in future because the
> Kernel comes with the promise that userspace won't be broke.
>

History knows interfaces that were long deprecated, triggered warnings
and were eventually removed (sysctl?). We have not yet broken
user-space. IMO a warning is in order if an interface was deprecated.

> I can understand that you want to get rid of the global GPIO number
> space. Currently you can't, because there are still hundreds of
> in-Kernel users of the legacy API. When all these are fixed and the GPIO
> sysfs API is the only remaining user of the global GPIO number space
> then we could move the numbering to gpiolib-sysfs.c and no longer bother
> the core with it. At this point the sysfs API would be a GPIO consumer
> just like every other consumer and we could leave it there until only
> the oldest of us remember what it's good for.
>
> Instead of trying to remove the sysfs API I really think it would be a
> better strategy to push it into a corner where it can stay without
> being a maintenance burden.
>

We're also doing it step-by-step.

> Regarding the usage of libgpiod for our projects: I think one of the
> major shortcomings is that the character interface doesn't allow to
> just set a GPIO to a value and leave it in that state without having
> to keep the process alive. While you may argument that it's cleaner
> to go to a "safe state" (or "idle state") when the process finishes
> that's simply not the way how many projects out there work. Virtually
> everyone has scripts poking GPIO states into sysfs and currently you
> can't do this with the character device API. If you want to get rid
> of the sysfs API then you should work on making the character device
> API more attractive for users and I think this is one point could use
> some improvement.
>
> Sascha

On that note: as libgpiod v2.0 is almost ready for release, I started
working on the idea I've long had in mind - DBus interface for GPIOs.
I've started writing the code over Christmas and some very limited
functionality is available on my github[1]. For now it only allows to
read chip properties but my goal is to have a complete DBus API for
libgpiod v2.1. Is this something you could work with? It addresses
your main concern (having a central authority and persistent state of
GPIOs) while using the character device behind the scenes.

Bart

[1] https://github.com/brgl/libgpiod-private/tree/topic/dbus