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

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

[Robert P. J. Day]

  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.

rday

-- 

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

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

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

[Greg KH]

On Wed, May 24, 2017 at 07:58:19AM -0400, Robert P. J. Day wrote:
>   in any event, is the /dev/gpiochip* interface the recommended
> interface now?

Yes.

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

[Clemens Gruber]

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.

Cheers,
Clemens

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

[Robert P. J. Day]

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,@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
========================================================================

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

[Greg KH]

On Thu, May 25, 2017 at 03:02:24PM -0400, Robert P. J. Day wrote:
> 
>   thoughts?

Why not ask on the linux-gpio mailing list?

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

[Robert P. J. Day]

On Thu, 25 May 2017, Greg KH wrote:

> On Thu, May 25, 2017 at 03:02:24PM -0400, Robert P. J. Day wrote:
> >
> >   thoughts?
>
> Why not ask on the linux-gpio mailing list?

  huh, i didn't even know there was such a thing.

rday

-- 

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

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

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

[valdis.kletnieks at vt.edu]

On Thu, 25 May 2017 15:20:06 -0400, "Robert P. J. Day" said:
> On Thu, 25 May 2017, Greg KH wrote:
>
> > On Thu, May 25, 2017 at 03:02:24PM -0400, Robert P. J. Day wrote:
> > >
> > >   thoughts?
> >
> > Why not ask on the linux-gpio mailing list?
>
>   huh, i didn't even know there was such a thing.

See http://vger.kernel.org for most of them.  Or look in MAINTAINERS:

GPIO SUBSYSTEM
M:      Linus Walleij <linus.walleij@linaro.org>
M:      Alexandre Courbot <gnurou@gmail.com>
L:      linux-gpio at vger.kernel.org

:)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20170525/a89db3a8/attachment.bin 

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

[Robert P. J. Day]

On Thu, 25 May 2017, valdis.kletnieks at vt.edu wrote:

> On Thu, 25 May 2017 15:20:06 -0400, "Robert P. J. Day" said:
> > On Thu, 25 May 2017, Greg KH wrote:
> >
> > > On Thu, May 25, 2017 at 03:02:24PM -0400, Robert P. J. Day wrote:
> > > >
> > > >   thoughts?
> > >
> > > Why not ask on the linux-gpio mailing list?
> >
> >   huh, i didn't even know there was such a thing.
>
> See http://vger.kernel.org for most of them.  Or look in MAINTAINERS:
>
> GPIO SUBSYSTEM
> M:      Linus Walleij <linus.walleij@linaro.org>
> M:      Alexandre Courbot <gnurou@gmail.com>
> L:      linux-gpio at vger.kernel.org
>
> :)

  well, i'm pretty sure i can find it once i know what to look for.
:-)

rday

-- 

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

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================