State of userland access to GPIO based hardware?

[Lukas Zeller]

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 ;-)

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 23.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 that 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: http://lists.openwrt.org/pipermail/openwrt-devel/2021-November/037139.html.

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.openwrt.org/pipermail/openwrt-devel/attachments/20220620/47132c82/attachment.sig>