GPIO Sysfs Interface for Userspace

GPIO Sysfs Interface for Userspace==================================Platforms which use the "gpiolib" implementors framework may choose toconfigure a sysfs user interface to GPIOs. This is different from thedebugfs interface, since it provides control over GPIO direction andvalue instead of just showing a gpio state summary. Plus, it could bepresent on production systems without debugging support.Given appropriate hardware documentation for the system, userspace couldknow for example that GPIO #23 controls the write protect line used toprotect boot loader segments in flash memory. System upgrade proceduresmay need to temporarily remove that protection, first importing a GPIO,then changing its output state, then updating the code before re-enablingthe write protection. In normal use, GPIO #23 would never be touched,and the kernel would have no need to know about it.Again depending on appropriate hardware documentation, on some systemsuserspace GPIO can be used to determine system configuration data thatstandard kernels won't know about. And for some tasks, simple userspaceGPIO drivers could be all that the system really needs.Note that standard kernel drivers exist for common "LEDs and Buttons"GPIO tasks:  "leds-gpio" and "gpio_keys", respectively. Use thoseinstead of talking directly to the GPIOs; they integrate with kernelframeworks better than your userspace code could.Paths in Sysfs--------------There are three kinds of entry in /sys/class/gpio:   -Control interfaces used to get userspace control over GPIOs;   -GPIOs themselves; and   -GPIO controllers ("gpio_chip" instances).That's in addition to standard files including the "device" symlink.The control interfaces are write-only:    /sys/class/gpio/    "export" ... Userspace may ask the kernel to export control ofa GPIO to userspace by writing its number to this file.Example:  "echo 19 > export" will create a "gpio19" nodefor GPIO #19, if that's not requested by kernel code.    "unexport" ... Reverses the effect of exporting to userspace.Example:  "echo 19 > unexport" will remove a "gpio19"node exported using the "export" file.GPIO signals have paths like /sys/class/gpio/gpio42/ (for GPIO #42)and have the following read/write attributes:    /sys/class/gpio/gpioN/"direction" ... reads as either "in" or "out". This value maynormally be written. Writing as "out" defaults toinitializing the value as low. To ensure glitch freeoperation, values "low" and "high" may be written toconfigure the GPIO as an output with that initial value.Note that this attribute *will not exist* if the kerneldoesn't support changing the direction of a GPIO, orit was exported by kernel code that didn't explicitlyallow userspace to reconfigure this GPIO's direction."value" ... reads as either 0 (low) or 1 (high). If the GPIOis configured as an output, this value may be written;any nonzero value is treated as high.If the pin can be configured as interrupt-generating interruptand if it has been configured to generate interrupts (see thedescription of "edge"), you can poll(2) on that file andpoll(2) will return whenever the interrupt was triggered. Ifyou use poll(2), set the events POLLPRI and POLLERR. If youuse select(2), set the file descriptor in exceptfds. Afterpoll(2) returns, either lseek(2) to the beginning of the sysfsfile and read the new value or close the file and re-open itto read the value."edge" ... reads as either "none", "rising", "falling", or"both". Write these strings to select the signal edge(s)that will make poll(2) on the "value" file return.This file exists only if the pin can be configured as aninterrupt generating input pin."active_low" ... reads as either 0 (false) or 1 (true). Writeany nonzero value to invert the value attribute bothfor reading and writing. Existing and subsequentpoll(2) support configuration via the edge attributefor "rising" and "falling" edges will follow thissetting.GPIO controllers have paths like /sys/class/gpio/gpiochip42/ (for thecontroller implementing GPIOs starting at #42) and have the followingread-only attributes:    /sys/class/gpio/gpiochipN/    "base" ... same as N, the first GPIO managed by this chip    "label" ... provided for diagnostics (not always unique)    "ngpio" ... how many GPIOs this manges (N to N + ngpio - 1)Board documentation should in most cases cover what GPIOs are used forwhat purposes. However, those numbers are not always stable; GPIOs ona daughtercard might be different depending on the base board being used,or other cards in the stack. In such cases, you may need to use thegpiochip nodes (possibly in conjunction with schematics) to determinethe correct GPIO number to use for a given signal.Exporting from Kernel code--------------------------Kernel code can explicitly manage exports of GPIOs which have already beenrequested using gpio_request():/* export the GPIO to userspace */int gpiod_export(struct gpio_desc *desc, bool direction_may_change);/* reverse gpio_export() */void gpiod_unexport(struct gpio_desc *desc);/* create a sysfs link to an exported GPIO node */int gpiod_export_link(struct device *dev, const char *name,      struct gpio_desc *desc);After a kernel driver requests a GPIO, it may only be made available inthe sysfs interface by gpiod_export(). The driver can control whether thesignal direction may change. This helps drivers prevent userspace codefrom accidentally clobbering important system state.This explicit exporting can help with debugging (by making some kindsof experiments easier), or can provide an always-there interface that'ssuitable for documenting as part of a board support package.After the GPIO has been exported, gpiod_export_link() allows creatingsymlinks from elsewhere in sysfs to the GPIO sysfs node. Drivers canuse this to provide the interface under their own device in sysfs witha descriptive name.