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