This BoF session will discuss recent changes and current issues in gpio and pinctrl. Bartosz Golaszewski is the maintainer GPIO kernel subsystem and libgpiod and told me that he plans to attend. Linus Walleij is the pinctrl subsystem maintainer and told me he would like to participate if he can join remotely.
The gpio subsystem in the kernel gained a v2 uAPI in the recent years - in fact it was sparked by discussion with Linus Walleij in the last in-person LPC in 2019. The libgpiod user space library currently updating its C, C++ and Python bindings for the new v2 uAPI. In addition, Viresh Kumar is also working on Rust bindings. There is also discussion around creating a higher level more "pythonic" Python library for simple use-cases that don't need the full uAPI.
The sysfs gpio uapi is deprecated but some refuse to let it go in favor of gpiod. Some users complain that gpiod uapi is not sufficient replacement for use-cases where the state of a gpio line is critical to retain its current state regardless of what happens to the process that opened the gpiochip. Bartosz Golaszewski also has plans to expose the gpio uapi through d-bus daemon to address this issue by having the daemon be the process that holds that fd for the gpiochip.
For pinctrl, some users have long desired the ability to control pinctrl state from userspace. The gpiod v2 uAPI allowed some pinconf properties to be set such as bias (pull-up/pull-down). However, this is not sufficient for rapid prototyping where userspace wants to change the mode of a pin. I would like to discuss how the pinmux-select in pinctrl debugfs might be used.
[Please do not schedule this against the RISC-V MC as I need to attend that too.]
[It would be if this BoF was not on ELC-E overlap days as this topic is embedded focused and I expect those speaking at ELC-E may be interested to attend].
|I agree to abide by the anti-harassment policy||Yes|