gpio: doc updates
There's been some recent confusion about error checking GPIO numbers. briefly, it should be handled mostly during setup, when gpio_request() is called, and NEVER by expectig gpio_is_valid to report more than never-usable GPIO numbers. [akpm@linux-foundation.org: terminate unterminated comment] Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Cc: Eric Miao" <eric.y.miao@gmail.com> Cc: "Ryan Mallon" <ryan@bluewatersys.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This commit is contained in:
committed by
Linus Torvalds
parent
5affb60772
commit
c956126c13
@ -109,17 +109,19 @@ use numbers 2000-2063 to identify GPIOs in a bank of I2C GPIO expanders.
|
|||||||
|
|
||||||
If you want to initialize a structure with an invalid GPIO number, use
|
If you want to initialize a structure with an invalid GPIO number, use
|
||||||
some negative number (perhaps "-EINVAL"); that will never be valid. To
|
some negative number (perhaps "-EINVAL"); that will never be valid. To
|
||||||
test if a number could reference a GPIO, you may use this predicate:
|
test if such number from such a structure could reference a GPIO, you
|
||||||
|
may use this predicate:
|
||||||
|
|
||||||
int gpio_is_valid(int number);
|
int gpio_is_valid(int number);
|
||||||
|
|
||||||
A number that's not valid will be rejected by calls which may request
|
A number that's not valid will be rejected by calls which may request
|
||||||
or free GPIOs (see below). Other numbers may also be rejected; for
|
or free GPIOs (see below). Other numbers may also be rejected; for
|
||||||
example, a number might be valid but unused on a given board.
|
example, a number might be valid but temporarily unused on a given board.
|
||||||
|
|
||||||
Whether a platform supports multiple GPIO controllers is currently a
|
|
||||||
platform-specific implementation issue.
|
|
||||||
|
|
||||||
|
Whether a platform supports multiple GPIO controllers is a platform-specific
|
||||||
|
implementation issue, as are whether that support can leave "holes" in the space
|
||||||
|
of GPIO numbers, and whether new controllers can be added at runtime. Such issues
|
||||||
|
can affect things including whether adjacent GPIO numbers are both valid.
|
||||||
|
|
||||||
Using GPIOs
|
Using GPIOs
|
||||||
-----------
|
-----------
|
||||||
@ -480,12 +482,16 @@ To support this framework, a platform's Kconfig will "select" either
|
|||||||
ARCH_REQUIRE_GPIOLIB or ARCH_WANT_OPTIONAL_GPIOLIB
|
ARCH_REQUIRE_GPIOLIB or ARCH_WANT_OPTIONAL_GPIOLIB
|
||||||
and arrange that its <asm/gpio.h> includes <asm-generic/gpio.h> and defines
|
and arrange that its <asm/gpio.h> includes <asm-generic/gpio.h> and defines
|
||||||
three functions: gpio_get_value(), gpio_set_value(), and gpio_cansleep().
|
three functions: gpio_get_value(), gpio_set_value(), and gpio_cansleep().
|
||||||
They may also want to provide a custom value for ARCH_NR_GPIOS.
|
|
||||||
|
|
||||||
ARCH_REQUIRE_GPIOLIB means that the gpio-lib code will always get compiled
|
It may also provide a custom value for ARCH_NR_GPIOS, so that it better
|
||||||
|
reflects the number of GPIOs in actual use on that platform, without
|
||||||
|
wasting static table space. (It should count both built-in/SoC GPIOs and
|
||||||
|
also ones on GPIO expanders.
|
||||||
|
|
||||||
|
ARCH_REQUIRE_GPIOLIB means that the gpiolib code will always get compiled
|
||||||
into the kernel on that architecture.
|
into the kernel on that architecture.
|
||||||
|
|
||||||
ARCH_WANT_OPTIONAL_GPIOLIB means the gpio-lib code defaults to off and the user
|
ARCH_WANT_OPTIONAL_GPIOLIB means the gpiolib code defaults to off and the user
|
||||||
can enable it and build it into the kernel optionally.
|
can enable it and build it into the kernel optionally.
|
||||||
|
|
||||||
If neither of these options are selected, the platform does not support
|
If neither of these options are selected, the platform does not support
|
||||||
|
@ -16,15 +16,27 @@
|
|||||||
* While the GPIO programming interface defines valid GPIO numbers
|
* While the GPIO programming interface defines valid GPIO numbers
|
||||||
* to be in the range 0..MAX_INT, this library restricts them to the
|
* to be in the range 0..MAX_INT, this library restricts them to the
|
||||||
* smaller range 0..ARCH_NR_GPIOS-1.
|
* smaller range 0..ARCH_NR_GPIOS-1.
|
||||||
|
*
|
||||||
|
* ARCH_NR_GPIOS is somewhat arbitrary; it usually reflects the sum of
|
||||||
|
* builtin/SoC GPIOs plus a number of GPIOs on expanders; the latter is
|
||||||
|
* actually an estimate of a board-specific value.
|
||||||
*/
|
*/
|
||||||
|
|
||||||
#ifndef ARCH_NR_GPIOS
|
#ifndef ARCH_NR_GPIOS
|
||||||
#define ARCH_NR_GPIOS 256
|
#define ARCH_NR_GPIOS 256
|
||||||
#endif
|
#endif
|
||||||
|
|
||||||
|
/*
|
||||||
|
* "valid" GPIO numbers are nonnegative and may be passed to
|
||||||
|
* setup routines like gpio_request(). only some valid numbers
|
||||||
|
* can successfully be requested and used.
|
||||||
|
*
|
||||||
|
* Invalid GPIO numbers are useful for indicating no-such-GPIO in
|
||||||
|
* platform data and other tables.
|
||||||
|
*/
|
||||||
|
|
||||||
static inline int gpio_is_valid(int number)
|
static inline int gpio_is_valid(int number)
|
||||||
{
|
{
|
||||||
/* only some non-negative numbers are valid */
|
|
||||||
return ((unsigned)number) < ARCH_NR_GPIOS;
|
return ((unsigned)number) < ARCH_NR_GPIOS;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
Reference in New Issue
Block a user