what is the current/ongoing state of userspace access to GPIO?
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 ========================================================================
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
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 ========================================================================
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 ========================================================================
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@vger.kernel.org :)
On Thu, 25 May 2017, valdis.kletnieks@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@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 ========================================================================
participants (4)
-
Clemens Gruber -
Greg KH -
Robert P. J. Day -
valdis.kletnieks＠vt.edu