summaryrefslogtreecommitdiff
path: root/Documentation/driver-api
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2024-03-13 21:14:55 +0300
committerLinus Torvalds <torvalds@linux-foundation.org>2024-03-13 21:14:55 +0300
commit69afef4af453c913e31640f3b31103847b97fe2f (patch)
tree5d81e6d8ec6abfed91f173050f6d7987d869ed65 /Documentation/driver-api
parent6cdebf62a159f31351946685b02941c968b96e49 (diff)
parent8636f19c2d1f8199b27b4559d9caa115b3011f06 (diff)
downloadlinux-69afef4af453c913e31640f3b31103847b97fe2f.tar.xz
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/driver-api')
-rw-r--r--Documentation/driver-api/gpio/consumer.rst10
1 files changed, 5 insertions, 5 deletions
diff --git a/Documentation/driver-api/gpio/consumer.rst b/Documentation/driver-api/gpio/consumer.rst
index 3e588b9d678c..ab56ab0dd7a6 100644
--- a/Documentation/driver-api/gpio/consumer.rst
+++ b/Documentation/driver-api/gpio/consumer.rst
@@ -222,9 +222,9 @@ Use the following calls to access GPIOs from an atomic context::
int gpiod_get_value(const struct gpio_desc *desc);
void gpiod_set_value(struct gpio_desc *desc, int value);
-The values are boolean, zero for low, nonzero for high. When reading the value
-of an output pin, the value returned should be what's seen on the pin. That
-won't always match the specified output value, because of issues including
+The values are boolean, zero for inactive, nonzero for active. When reading the
+value of an output pin, the value returned should be what's seen on the pin.
+That won't always match the specified output value, because of issues including
open-drain signaling and output latencies.
The get/set calls do not return errors because "invalid GPIO" should have been
@@ -277,11 +277,11 @@ switch their output to a high impedance value. The consumer should not need to
care. (For details read about open drain in driver.rst.)
With this, all the gpiod_set_(array)_value_xxx() functions interpret the
-parameter "value" as "asserted" ("1") or "de-asserted" ("0"). The physical line
+parameter "value" as "active" ("1") or "inactive" ("0"). The physical line
level will be driven accordingly.
As an example, if the active low property for a dedicated GPIO is set, and the
-gpiod_set_(array)_value_xxx() passes "asserted" ("1"), the physical line level
+gpiod_set_(array)_value_xxx() passes "active" ("1"), the physical line level
will be driven low.
To summarize::