aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/Documentation/admin-guide
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2024-03-13 11:14:55 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2024-03-13 11:14:55 -0700
commit69afef4af453c913e31640f3b31103847b97fe2f (patch)
tree5d81e6d8ec6abfed91f173050f6d7987d869ed65 /Documentation/admin-guide
parentMerge tag 'spi-v6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi (diff)
parentgpio: sysfs: repair export returning -EPERM on 1st attempt (diff)
downloadwireguard-linux-69afef4af453c913e31640f3b31103847b97fe2f.tar.xz
wireguard-linux-69afef4af453c913e31640f3b31103847b97fe2f.zip
Merge tag 'gpio-updates-for-v6.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
Pull gpio updates from Bartosz Golaszewski: "The biggest feature is the locking overhaul. Up until now the synchronization in the GPIO subsystem was broken. There was a single spinlock "protecting" multiple data structures but doing it wrong (as evidenced by several places where it would be released when a sleeping function was called and then reacquired without checking the protected state). We tried to use an RW semaphore before but the main issue with GPIO is that we have drivers implementing the interfaces in both sleeping and non-sleeping ways as well as user-facing interfaces that can be called both from process as well as atomic contexts. Both ends converge in the same code paths that can use neither spinlocks nor mutexes. The only reasonable way out is to use SRCU and go mostly lockless. To that end: we add several SRCU structs in relevant places and use them to assure consistency between API calls together with atomic reads and writes of GPIO descriptor flags where it makes sense. This code has spent several weeks in next and has received several fixes in the first week or two after which it stabilized nicely. The GPIO subsystem is now resilient to providers being suddenly unbound. We managed to also remove the existing character device RW semaphore and the obsolete global spinlock. Other than the locking rework we have one new driver (for Chromebook EC), much appreciated documentation improvements from Kent and the regular driver improvements, DT-bindings updates and GPIOLIB core tweaks. Serialization rework: - use SRCU to serialize access to the global GPIO device list, to GPIO device structs themselves and to GPIO descriptors - make the GPIO subsystem resilient to the GPIO providers being unbound while the API calls are in progress - don't dereference the SRCU-protected chip pointer if the information we need can be obtained from the GPIO device structure - move some of the information contained in struct gpio_chip to struct gpio_device to further reduce the need to dereference the former - pass the GPIO device struct instead of the GPIO chip to sysfs callback to, again, reduce the need for accessing the latter - get GPIO descriptors from the GPIO device, not from the chip for the same reason - allow for mostly lockless operation of the GPIO driver API: assure consistency with SRCU and atomic operations - remove the global GPIO spinlock - remove the character device RW semaphore Core GPIOLIB: - constify pointers in GPIO API where applicable - unify the GPIO counting APIs for ACPI and OF - provide a macro for iterating over all GPIOs, not only the ones that are requested - remove leftover typedefs - pass the consumer device to GPIO core in devm_fwnode_gpiod_get_index() for improved logging - constify the GPIO bus type - don't warn about removing GPIO chips with descriptors still held by users as we can now handle this situation gracefully - remove unused logging helpers - unexport functions that are only used internally in the GPIO subsystem - set the device type (assign the relevant struct device_type) for GPIO devices New drivers: - add the ChromeOS EC GPIO driver Driver improvements: - allow building gpio-vf610 with COMPILE_TEST as well as disabling it in menuconfig (before it was always built for i.MX cofigs) - count the number of EICs using the device properties instead of hard-coding it in gpio-eic-sprd - improve the device naming, extend the debugfs output and add lockdep asserts to gpio-sim DT bindings: - document the 'label' property for gpio-pca9570 - convert aspeed,ast2400-gpio bindings to DT schema - disallow unevaluated properties for gpio-mvebu - document a new model in renesas,rcar-gpio Documentation: - improve the character device kerneldocs in user-space headers - add proper documentation for the character device uAPI (both v1 and v2) - move the sysfs and gpio-mockup docs into the "obsolete" section - improve naming consistency for GPIO terms - clarify the line values description for sysfs - minor docs improvements - improve the driver API contract for setting GPIO direction - mark unsafe APIs as deprecated in kerneldocs and suggest replacements Other: - remove an obsolete test from selftests" * tag 'gpio-updates-for-v6.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: (79 commits) gpio: sysfs: repair export returning -EPERM on 1st attempt selftest: gpio: remove obsolete gpio-mockup test gpiolib: Deduplicate cleanup for-loop in gpiochip_add_data_with_key() dt-bindings: gpio: aspeed,ast2400-gpio: Convert to DT schema gpio: acpi: Make acpi_gpio_count() take firmware node as a parameter gpio: of: Make of_gpio_get_count() take firmware node as a parameter gpiolib: Pass consumer device through to core in devm_fwnode_gpiod_get_index() gpio: sim: use for_each_hwgpio() gpio: provide for_each_hwgpio() gpio: don't warn about removing GPIO chips with active users anymore gpio: sim: delimit the fwnode name with a ":" when generating labels gpio: sim: add lockdep asserts gpio: Add ChromeOS EC GPIO driver gpio: constify of_phandle_args in of_find_gpio_device_by_xlate() gpio: fix memory leak in gpiod_request_commit() gpio: constify opaque pointer "data" in gpio_device_find() gpio: cdev: fix a NULL-pointer dereference with DEBUG enabled gpio: uapi: clarify default_values being logical gpio: sysfs: fix inverted pointer logic gpio: don't let lockdep complain about inherently dangerous RCU usage ...
Diffstat (limited to 'Documentation/admin-guide')
-rw-r--r--Documentation/admin-guide/gpio/gpio-mockup.rst8
-rw-r--r--Documentation/admin-guide/gpio/index.rst6
-rw-r--r--Documentation/admin-guide/gpio/obsolete.rst13
-rw-r--r--Documentation/admin-guide/gpio/sysfs.rst167
4 files changed, 24 insertions, 170 deletions
diff --git a/Documentation/admin-guide/gpio/gpio-mockup.rst b/Documentation/admin-guide/gpio/gpio-mockup.rst
index 493071da1738..d6e7438a7550 100644
--- a/Documentation/admin-guide/gpio/gpio-mockup.rst
+++ b/Documentation/admin-guide/gpio/gpio-mockup.rst
@@ -3,6 +3,14 @@
GPIO Testing Driver
===================
+.. note::
+
+ This module has been obsoleted by the more flexible gpio-sim.rst.
+ New developments should use that API and existing developments are
+ encouraged to migrate as soon as possible.
+ This module will continue to be maintained but no new features will be
+ added.
+
The GPIO Testing Driver (gpio-mockup) provides a way to create simulated GPIO
chips for testing purposes. The lines exposed by these chips can be accessed
using the standard GPIO character device interface as well as manipulated
diff --git a/Documentation/admin-guide/gpio/index.rst b/Documentation/admin-guide/gpio/index.rst
index f6861ca16ffe..460afd29617e 100644
--- a/Documentation/admin-guide/gpio/index.rst
+++ b/Documentation/admin-guide/gpio/index.rst
@@ -1,16 +1,16 @@
.. SPDX-License-Identifier: GPL-2.0
====
-gpio
+GPIO
====
.. toctree::
:maxdepth: 1
+ Character Device Userspace API <../../userspace-api/gpio/chardev>
gpio-aggregator
- sysfs
- gpio-mockup
gpio-sim
+ Obsolete APIs <obsolete>
.. only:: subproject and html
diff --git a/Documentation/admin-guide/gpio/obsolete.rst b/Documentation/admin-guide/gpio/obsolete.rst
new file mode 100644
index 000000000000..5adbff02d61f
--- /dev/null
+++ b/Documentation/admin-guide/gpio/obsolete.rst
@@ -0,0 +1,13 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==================
+Obsolete GPIO APIs
+==================
+
+.. toctree::
+ :maxdepth: 1
+
+ Character Device Userspace API (v1) <../../userspace-api/gpio/chardev_v1>
+ Sysfs Interface <../../userspace-api/gpio/sysfs>
+ Mockup Testing Module <gpio-mockup>
+
diff --git a/Documentation/admin-guide/gpio/sysfs.rst b/Documentation/admin-guide/gpio/sysfs.rst
deleted file mode 100644
index 35171d15f78d..000000000000
--- a/Documentation/admin-guide/gpio/sysfs.rst
+++ /dev/null
@@ -1,167 +0,0 @@
-GPIO Sysfs Interface for Userspace
-==================================
-
-.. warning::
-
- THIS ABI IS DEPRECATED, THE ABI DOCUMENTATION HAS BEEN MOVED TO
- Documentation/ABI/obsolete/sysfs-gpio AND NEW USERSPACE CONSUMERS
- ARE SUPPOSED TO USE THE CHARACTER DEVICE ABI. THIS OLD SYSFS ABI WILL
- NOT BE DEVELOPED (NO NEW FEATURES), IT WILL JUST BE MAINTAINED.
-
-Refer to the examples in tools/gpio/* for an introduction to the new
-character device ABI. Also see the userspace header in
-include/uapi/linux/gpio.h
-
-The deprecated sysfs ABI
-------------------------
-Platforms which use the "gpiolib" implementors framework may choose to
-configure a sysfs user interface to GPIOs. This is different from the
-debugfs interface, since it provides control over GPIO direction and
-value instead of just showing a gpio state summary. Plus, it could be
-present on production systems without debugging support.
-
-Given appropriate hardware documentation for the system, userspace could
-know for example that GPIO #23 controls the write protect line used to
-protect boot loader segments in flash memory. System upgrade procedures
-may need to temporarily remove that protection, first importing a GPIO,
-then changing its output state, then updating the code before re-enabling
-the 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 systems
-userspace GPIO can be used to determine system configuration data that
-standard kernels won't know about. And for some tasks, simple userspace
-GPIO drivers could be all that the system really needs.
-
-DO NOT ABUSE SYSFS TO CONTROL HARDWARE THAT HAS PROPER KERNEL DRIVERS.
-PLEASE READ THE DOCUMENT AT Documentation/driver-api/gpio/drivers-on-gpio.rst
-TO AVOID REINVENTING KERNEL WHEELS IN USERSPACE. I MEAN IT. REALLY.
-
-Paths in Sysfs
---------------
-There are three kinds of entries 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 of
- a GPIO to userspace by writing its number to this file.
-
- Example: "echo 19 > export" will create a "gpio19" node
- for 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 may
- normally be written. Writing as "out" defaults to
- initializing the value as low. To ensure glitch free
- operation, values "low" and "high" may be written to
- configure the GPIO as an output with that initial value.
-
- Note that this attribute *will not exist* if the kernel
- doesn't support changing the direction of a GPIO, or
- it was exported by kernel code that didn't explicitly
- allow userspace to reconfigure this GPIO's direction.
-
- "value" ...
- reads as either 0 (low) or 1 (high). If the GPIO
- is 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 interrupt
- and if it has been configured to generate interrupts (see the
- description of "edge"), you can poll(2) on that file and
- poll(2) will return whenever the interrupt was triggered. If
- you use poll(2), set the events POLLPRI and POLLERR. If you
- use select(2), set the file descriptor in exceptfds. After
- poll(2) returns, either lseek(2) to the beginning of the sysfs
- file and read the new value or close the file and re-open it
- to 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 an
- interrupt generating input pin.
-
- "active_low" ...
- reads as either 0 (false) or 1 (true). Write
- any nonzero value to invert the value attribute both
- for reading and writing. Existing and subsequent
- poll(2) support configuration via the edge attribute
- for "rising" and "falling" edges will follow this
- setting.
-
-GPIO controllers have paths like /sys/class/gpio/gpiochip42/ (for the
-controller implementing GPIOs starting at #42) and have the following
-read-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 manages (N to N + ngpio - 1)
-
-Board documentation should in most cases cover what GPIOs are used for
-what purposes. However, those numbers are not always stable; GPIOs on
-a 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 the
-gpiochip nodes (possibly in conjunction with schematics) to determine
-the correct GPIO number to use for a given signal.
-
-
-Exporting from Kernel code
---------------------------
-Kernel code can explicitly manage exports of GPIOs which have already been
-requested using gpio_request()::
-
- /* export the GPIO to userspace */
- int gpiod_export(struct gpio_desc *desc, bool direction_may_change);
-
- /* reverse gpiod_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 in
-the sysfs interface by gpiod_export(). The driver can control whether the
-signal direction may change. This helps drivers prevent userspace code
-from accidentally clobbering important system state.
-
-This explicit exporting can help with debugging (by making some kinds
-of experiments easier), or can provide an always-there interface that's
-suitable for documenting as part of a board support package.
-
-After the GPIO has been exported, gpiod_export_link() allows creating
-symlinks from elsewhere in sysfs to the GPIO sysfs node. Drivers can
-use this to provide the interface under their own device in sysfs with
-a descriptive name.