Expose named GPIOs through sysfs

Expose named GPIOs through sysfs

[Kevin Smith]

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/linux-gpio@vger.kernel.org/msg00864.html
[2] https://www.mail-archive.com/linux-gpio@vger.kernel.org/msg01084.html

Re: Expose named GPIOs through sysfs

[Linus Walleij]

On Wed, May 18, 2016 at 10:43 PM, Kevin Smith
<kevin.smith@elecsyscorp.com> wrote:

> 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.

> 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?

>  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.

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

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

> 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