* Expose named GPIOs through sysfs
@ 2016-05-18 20:43 Kevin Smith
2016-06-14 7:31 ` Linus Walleij
0 siblings, 1 reply; 2+ messages in thread
From: Kevin Smith @ 2016-05-18 20:43 UTC (permalink / raw)
To: linux-gpio
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Expose named GPIOs through sysfs
2016-05-18 20:43 Expose named GPIOs through sysfs Kevin Smith
@ 2016-06-14 7:31 ` Linus Walleij
0 siblings, 0 replies; 2+ messages in thread
From: Linus Walleij @ 2016-06-14 7:31 UTC (permalink / raw)
To: Kevin Smith; +Cc: linux-gpio
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2016-06-14 7:31 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-05-18 20:43 Expose named GPIOs through sysfs Kevin Smith
2016-06-14 7:31 ` Linus Walleij
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.