Expose named GPIOs through sysfs
Hello,
I have several GPIOs that are not associated with kernel drivers that I would like to expose to userspace with names corresponding to their functions. I am on Arm, so I would like to be able to specify this through a device tree.
As a concrete example, I have a USB device that is controlled with a userspace libusb driver which has a reset pin connected by GPIO. I would like to expose this line as dev_reset. Right now, userspace has to know the GPIO number, export the gpio, manually configure it as an output, then set its value. Instead, I would like the device to simply show up as /sys/class/gpio/dev_reset/ (or similar) with the expected GPIO properties in this directory.
As a workaround, I have seen some people configure GPIOs with the LED driver and control the pin with "brightness", but this seems like a hack. I am aware of gpio-hog, but as far as I can tell, once hogged, the GPIO is not exposed and cannot be changed (at least by userspace).
I see that there have been similar discussions before [1], but they don't seem to have reached a conclusion. Before working on something, I wanted to contact the list to get some direction on the right way to proceed. Is a dedicated driver the right way to do this? Or an option added to the GPIO system? I see some proposals in [2] ... is implementing the suggestions there the best way?
Thank you,
Kevin Smith
[1] https://www.mail-archive.com/[email protected]/msg00864.html
[2] https://www.mail-archive.com/[email protected]/msg01084.html
Quoted 4 lines · Kevin Smith
I have several GPIOs that are not associated with kernel drivers that I would like to expose to userspace with names corresponding to their functions. I am on Arm, so I would like to be able to specify this through a device tree.
You can now use gpio-line-names = ... to name GPIO lines on DT systems, see
commit fd9c55315db9bc89c54bb644a0f8b1f9306010d4 "gpio: of: make it possible to name GPIO lines"
Using "lsgpio" from tools/gpio you should be able to see a list of GPIO controllers, their lines, and line names. More details of the gpiochip topology can then be read from sysfs if need be.
Quoted 2 lines
As a concrete example, I have a USB device that is controlled with a userspace libusb driver which has a reset pin connected by GPIO.
This seems super fragile. I hope you are just considering this for prototyping and not as a permanent solution for random users?
Quoted 6 lines
I
would like to expose this line asdev_reset. Right now, userspace has to know the GPIO number, export the gpio, manually configure it as an output, then set its value. Instead, I would like the device to simply show up as/sys/class/gpio/dev_reset/(or similar) with the expected GPIO properties in this directory.
This ABI is obsoleted. We are working on the new character device to do what you want to do. I am busy iterating it and plan to merge it for kernel v4.8:
https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-gpio.git/log/?h=chardev-step-2
Quoted 3 lines
As a workaround, I have seen some people configure GPIOs with the LED driver and control the pin with "brightness", but this seems like a hack.
Urrrk no.
Read Documentation/gpio/drivers-on-gpio.txt
I think two things:
1. Should such a complex device really be handled by libusb? I mean libusb has this nice microkernel feeling about it for scanners and media players, but it is implicit that it is "just USB" no extra wires. I suspect libusb should be used for prototyping but the device should have a real kernel driver, because the hardware is too complex for userspace access only. A kernel driver can handle that complexity.
2. If you insist, I think drivers/reset/* should have some external userspace ABI (which it doesn't today).
Quoted 2 lines
I am aware of gpio-hog, but as far as I can tell, once hogged, the GPIO is not exposed and cannot be changed (at least by userspace).
That is not the usecase for hogs. Hogs are "set once, never touch".
Yours,
Linus Walleij