isdn: guard against a potential NULL pointer dereference in old_capi_manufacturer()

[cascardo/linux.git] / Documentation / gpio.txt

diff --git a/Documentation/gpio.txt b/Documentation/gpio.txt
index e8be0ab..6bc2ba2 100644 (file)
--- a/Documentation/gpio.txt
+++ b/Documentation/gpio.txt
@@ -75,6 +75,9 @@ using the include file:
 If you stick to this convention then it'll be easier for other developers to
 see what your code is doing, and help maintain it.
 
+Note that these operations include I/O barriers on platforms which need to
+use them; drivers don't need to add them explicitly.
+
 
 Identifying GPIOs
 -----------------
@@ -111,7 +114,9 @@ setting up a platform_device using the GPIO, is mark its direction:
 
 The return value is zero for success, else a negative errno.  It should
 be checked, since the get/set calls don't have error returns and since
-misconfiguration is possible.  (These calls could sleep.)
+misconfiguration is possible.  You should normally issue these calls from
+a task context.  However, for spinlock-safe GPIOs it's OK to use them
+before tasking is enabled, as part of early board setup.
 
 For output GPIOs, the value provided becomes the initial output value.
 This helps avoid signal glitching during system startup.
@@ -143,7 +148,7 @@ pin ... that won't always match the specified output value, because of
 issues including wire-OR and output latencies.
 
 The get/set calls have no error returns because "invalid GPIO" should have
-been reported earlier in gpio_set_direction().  However, note that not all
+been reported earlier from gpio_direction_*().  However, note that not all
 platforms can read the value of output pins; those that can't should always
 return zero.  Also, using these calls for GPIOs that can't safely be accessed
 without sleeping (see below) is an error.
@@ -197,7 +202,9 @@ However, many platforms don't currently support this mechanism.
 
 Passing invalid GPIO numbers to gpio_request() will fail, as will requesting
 GPIOs that have already been claimed with that call.  The return value of
-gpio_request() must be checked.  (These calls could sleep.)
+gpio_request() must be checked.  You should normally issue these calls from
+a task context.  However, for spinlock-safe GPIOs it's OK to request GPIOs
+before tasking is enabled, as part of early board setup.
 
 These calls serve two basic purposes.  One is marking the signals which
 are actually in use as GPIOs, for better diagnostics; systems may have
@@ -232,7 +239,7 @@ map between them using calls like:
 Those return either the corresponding number in the other namespace, or
 else a negative errno code if the mapping can't be done.  (For example,
 some GPIOs can't used as IRQs.)  It is an unchecked error to use a GPIO
-number that hasn't been marked as an input using gpio_set_direction(), or
+number that wasn't set up as an input using gpio_direction_input(), or
 to use an IRQ number that didn't originally come from gpio_to_irq().
 
 These two mapping calls are expected to cost on the order of a single