aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/Documentation/driver-api/gpio/consumer.rst
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/driver-api/gpio/consumer.rst')
-rw-r--r--Documentation/driver-api/gpio/consumer.rst14
1 files changed, 9 insertions, 5 deletions
diff --git a/Documentation/driver-api/gpio/consumer.rst b/Documentation/driver-api/gpio/consumer.rst
index de6fc79ad6f0..ab56ab0dd7a6 100644
--- a/Documentation/driver-api/gpio/consumer.rst
+++ b/Documentation/driver-api/gpio/consumer.rst
@@ -29,6 +29,10 @@ warnings. These stubs are used for two use cases:
will use it under other compile-time configurations. In this case the
consumer must make sure not to call into these functions, or the user will
be met with console warnings that may be perceived as intimidating.
+ Combining truly optional GPIOLIB usage with calls to
+ ``[devm_]gpiod_get_optional()`` is a *bad idea*, and will result in weird
+ error messages. Use the ordinary getter functions with optional GPIOLIB:
+ some open coding of error handling should be expected when you do this.
All the functions that work with the descriptor-based GPIO interface are
prefixed with ``gpiod_``. The ``gpio_`` prefix is used for the legacy
@@ -218,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
@@ -273,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::