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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 24 May 2017, Clemens Gruber wrote:

> Hi,
>
> On Wed, May 24, 2017 at 07:58:19AM -0400, Robert P. J. Day wrote:
> >
> >   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, at 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
========================================================================

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies



[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux