1GPIO Sysfs Interface for Userspace 2================================== 3 4THIS ABI IS DEPRECATED, THE ABI DOCUMENTATION HAS BEEN MOVED TO 5Documentation/ABI/obsolete/sysfs-gpio AND NEW USERSPACE CONSUMERS 6ARE SUPPOSED TO USE THE CHARACTER DEVICE ABI. THIS OLD SYSFS ABI WILL 7NOT BE DEVELOPED (NO NEW FEATURES), IT WILL JUST BE MAINTAINED. 8 9Refer to the examples in tools/gpio/* for an introduction to the new 10character device ABI. Also see the userspace header in 11include/uapi/linux/gpio.h 12 13The deprecated sysfs ABI 14------------------------ 15Platforms which use the "gpiolib" implementors framework may choose to 16configure a sysfs user interface to GPIOs. This is different from the 17debugfs interface, since it provides control over GPIO direction and 18value instead of just showing a gpio state summary. Plus, it could be 19present on production systems without debugging support. 20 21Given appropriate hardware documentation for the system, userspace could 22know for example that GPIO #23 controls the write protect line used to 23protect boot loader segments in flash memory. System upgrade procedures 24may need to temporarily remove that protection, first importing a GPIO, 25then changing its output state, then updating the code before re-enabling 26the write protection. In normal use, GPIO #23 would never be touched, 27and the kernel would have no need to know about it. 28 29Again depending on appropriate hardware documentation, on some systems 30userspace GPIO can be used to determine system configuration data that 31standard kernels won't know about. And for some tasks, simple userspace 32GPIO drivers could be all that the system really needs. 33 34DO NOT ABUSE SYSFS TO CONTROL HARDWARE THAT HAS PROPER KERNEL DRIVERS. 35PLEASE READ THE DOCUMENT AT Documentation/driver-api/gpio/drivers-on-gpio.rst 36TO AVOID REINVENTING KERNEL WHEELS IN USERSPACE. I MEAN IT. REALLY. 37 38Paths in Sysfs 39-------------- 40There are three kinds of entries in /sys/class/gpio: 41 42 - Control interfaces used to get userspace control over GPIOs; 43 44 - GPIOs themselves; and 45 46 - GPIO controllers ("gpio_chip" instances). 47 48That's in addition to standard files including the "device" symlink. 49 50The control interfaces are write-only: 51 52 /sys/class/gpio/ 53 54 "export" ... Userspace may ask the kernel to export control of 55 a GPIO to userspace by writing its number to this file. 56 57 Example: "echo 19 > export" will create a "gpio19" node 58 for GPIO #19, if that's not requested by kernel code. 59 60 "unexport" ... Reverses the effect of exporting to userspace. 61 62 Example: "echo 19 > unexport" will remove a "gpio19" 63 node exported using the "export" file. 64 65GPIO signals have paths like /sys/class/gpio/gpio42/ (for GPIO #42) 66and have the following read/write attributes: 67 68 /sys/class/gpio/gpioN/ 69 70 "direction" ... reads as either "in" or "out". This value may 71 normally be written. Writing as "out" defaults to 72 initializing the value as low. To ensure glitch free 73 operation, values "low" and "high" may be written to 74 configure the GPIO as an output with that initial value. 75 76 Note that this attribute *will not exist* if the kernel 77 doesn't support changing the direction of a GPIO, or 78 it was exported by kernel code that didn't explicitly 79 allow userspace to reconfigure this GPIO's direction. 80 81 "value" ... reads as either 0 (low) or 1 (high). If the GPIO 82 is configured as an output, this value may be written; 83 any nonzero value is treated as high. 84 85 If the pin can be configured as interrupt-generating interrupt 86 and if it has been configured to generate interrupts (see the 87 description of "edge"), you can poll(2) on that file and 88 poll(2) will return whenever the interrupt was triggered. If 89 you use poll(2), set the events POLLPRI and POLLERR. If you 90 use select(2), set the file descriptor in exceptfds. After 91 poll(2) returns, either lseek(2) to the beginning of the sysfs 92 file and read the new value or close the file and re-open it 93 to read the value. 94 95 "edge" ... reads as either "none", "rising", "falling", or 96 "both". Write these strings to select the signal edge(s) 97 that will make poll(2) on the "value" file return. 98 99 This file exists only if the pin can be configured as an 100 interrupt generating input pin. 101 102 "active_low" ... reads as either 0 (false) or 1 (true). Write 103 any nonzero value to invert the value attribute both 104 for reading and writing. Existing and subsequent 105 poll(2) support configuration via the edge attribute 106 for "rising" and "falling" edges will follow this 107 setting. 108 109GPIO controllers have paths like /sys/class/gpio/gpiochip42/ (for the 110controller implementing GPIOs starting at #42) and have the following 111read-only attributes: 112 113 /sys/class/gpio/gpiochipN/ 114 115 "base" ... same as N, the first GPIO managed by this chip 116 117 "label" ... provided for diagnostics (not always unique) 118 119 "ngpio" ... how many GPIOs this manages (N to N + ngpio - 1) 120 121Board documentation should in most cases cover what GPIOs are used for 122what purposes. However, those numbers are not always stable; GPIOs on 123a daughtercard might be different depending on the base board being used, 124or other cards in the stack. In such cases, you may need to use the 125gpiochip nodes (possibly in conjunction with schematics) to determine 126the correct GPIO number to use for a given signal. 127 128 129Exporting from Kernel code 130-------------------------- 131Kernel code can explicitly manage exports of GPIOs which have already been 132requested using gpio_request(): 133 134 /* export the GPIO to userspace */ 135 int gpiod_export(struct gpio_desc *desc, bool direction_may_change); 136 137 /* reverse gpio_export() */ 138 void gpiod_unexport(struct gpio_desc *desc); 139 140 /* create a sysfs link to an exported GPIO node */ 141 int gpiod_export_link(struct device *dev, const char *name, 142 struct gpio_desc *desc); 143 144After a kernel driver requests a GPIO, it may only be made available in 145the sysfs interface by gpiod_export(). The driver can control whether the 146signal direction may change. This helps drivers prevent userspace code 147from accidentally clobbering important system state. 148 149This explicit exporting can help with debugging (by making some kinds 150of experiments easier), or can provide an always-there interface that's 151suitable for documenting as part of a board support package. 152 153After the GPIO has been exported, gpiod_export_link() allows creating 154symlinks from elsewhere in sysfs to the GPIO sysfs node. Drivers can 155use this to provide the interface under their own device in sysfs with 156a descriptive name. 157
