Thread (8 messages) 8 messages, 4 authors, 2017-05-25

what is the current/ongoing state of userspace access to GPIO?

From: Robert P. J. Day <hidden>
Date: 2017-05-25 19:02:24

On Wed, 24 May 2017, Clemens Gruber wrote:
Hi,

On Wed, May 24, 2017 at 07:58:19AM -0400, Robert P. J. Day wrote:
quoted
  ashamed to admit, i haven't been keeping up with this, so AIUI,
the GPIO sysfs interface is deprecated, replaced with character
device files (/dev/gpiochip*) to allow access to GPIO.

  first, i find it curious that this is a move away from sysfs
access to using ioctl(), since i had always thought ioctls were
massively discouraged in new code. is there a document that goes
through the rationale for this change?

  and i notice under Documentation/ABI/ that sysfs-gpio is listed
under "obsolete", while gpio-cdev is listed under "testing". this
seems inconsistent -- how can one be obsolete while the other be
categorized as testing? that just seems strange.

  in any event, is the /dev/gpiochip* interface the recommended
interface now? thanks.
Linus Walleij described the rationale in the first commit
description. Have a look at 3c702e9987e2.

Implementing it with netlink sockets would have made it much more
complex, I suppose this is why they chose ioctl?

By the way, I can recommend accessing the GPIO chardev with
libgpiod: https://github.com/brgl/libgpiod

This simplifies using it a lot! The tools are also quite nice.
  thanks, now a couple more (admittedly trivial) questions as i claw
my way through the current state of gpio. the doc file "gpio.txt"
explains that there are two different ways to access GPIO:

  - The descriptor-based interface is the preferred way to manipulate
    GPIOs, and is described by all the files in this directory
    excepted gpio-legacy.txt.

  - The legacy integer-based interface which is considered deprecated
    (but still usable for compatibility reasons) is documented in
    gpio-legacy.txt.

the above *seems* to suggest that one can use the newer, preferred
descriptor-based interface and bypass the "legacy" interface, but if i
look in drivers/gpio/Makefile, i see:

  obj-$(CONFIG_GPIOLIB)           += devres.o
  obj-$(CONFIG_GPIOLIB)           += gpiolib.o
  obj-$(CONFIG_GPIOLIB)           += gpiolib-legacy.o  <--- ????
  obj-$(CONFIG_GPIOLIB)           += gpiolib-devprop.o

suggesting that if i select GPIOLIB, i get the legacy code compiled,
anyway. is that correct? it seems to disagree with the documentation,
unless that legacy source file is required no matter what,@which
point describing it as "legacy" seems misleading.

  thoughts?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help