State of userland access to GPIO based hardware?

For Developers
1

Hi all,

I'm trying to bring my OpenWrt-based IoT targets from 19.07 to 22.03. In this process I got a bit confused about the state of userland access to GPIOs.

I know that there is some ideology level discussion about userland GPIOs in general, and some strong opinions that these are not to be used for anything serious. As my target's very purpose is enabling the user to do things with GPIOs and software SPI/I2C from the application level, I can live with the verdict "not serious", but not without userland GPIOs :wink:

In 19.07 there was:

  • /sys/class/gpio for accessing individual GPIOs

  • kmod-spi-gpio-custom, kmod-i2c-gpio-custom to create bit-banged SPI/I2C on GPIOs

In 22.03:

  • /sys/class/gpio still exists, but is deprecated. Switching from explicit to automatic base in gpio_chip has changed the old-style datasheet aligned GPIO numbers to a very non-intuitive 512-gpiochipN*32 scheme (at least in my MT76x8 targets). The DT property gpio-base that was available in gpio-mt7621.c to set a custom base has been removed.

  • the new recommended access to GPIO from userland is now gpiod, however exists in a strange intermediate state where apparently the already deprecated v1 ABI needs to be enabled in the kernel (CONFIG_GPIO_CDEV_V1), because the official toolset for using gpiod from userland, libgpiod, has not been released yet in v2 which would support the current v2 ABI.

  • kmod-spi-gpio-custom and kmod-i2c-gpio-custom have been completely removed in "6362a04 - kernel: remove obsolete kernel version switches for 4.14".

This puts targets like mine in a situation with workable access to GPIOs (choosing between strange numbered old-style and deprecated V1 API based new style), but without any way to establish spi/i2c on GPIOs any more.

A elegant solution for using kmod-spi-gpio and similar (e.g. w1-gpio) drivers would have been device tree overlays loadable via configfs. Unfortunately, a patchset importing the needed configfs client has been rejected: openwrt-devel/2021-November/037139

So my bottom line questions would be:

  • what is the envisioned future for GPIO userland access in OpenWrt in general?
  • in particular, how to use kmod-gpio-i2c/spi/w1 etc. in 22.03 without baking the GPIO assignments into a fixed DT?

Best Regards,

Lukas

PS: of course I can (and currently do) patch all this such that it works for me, but my general goal is doing things as much as possible along the standard OpenWrt lines - which appear a bit blurred here, so that's why I ask.

PS: Sorry for duplicating this from the openwrt-devel mailing list to here - I guess the mailing list was the wrong place for the question in the first place...

4 Likes