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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.

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

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |



[Index of Archives]     [Linux SPI]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux