gpio: delete ARCH_[WANTS_OPTIONAL|REQUIRE]_GPIOLIB

The GPIOLIB is now selectable explicitly, and always available
for all archs. All archs that require GPIOLIB are switched to
select GPIOLIB directly. Delete the hairy ARCH_REQUIRE_GPIOLIB
and ARCH_WANTS_OPTIONAL_GPIOLIB Kconfig symbols.

Cc: Michael Büsch <m@bues.ch>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This commit is contained in:
Linus Walleij 2016-04-19 13:40:17 +02:00
parent 10e59a6488
commit 65053e1a77
3 changed files with 7 additions and 36 deletions

View file

@ -8,9 +8,9 @@ gpio-legacy.txt (actually, there is no real mapping possible with the old
interface; you just fetch an integer from somewhere and request the
corresponding GPIO.
Platforms that make use of GPIOs must select ARCH_REQUIRE_GPIOLIB (if GPIO usage
is mandatory) or ARCH_WANT_OPTIONAL_GPIOLIB (if GPIO support can be omitted) in
their Kconfig. Then, how GPIOs are mapped depends on what the platform uses to
All platforms can enable the GPIO library, but if the platform strictly
requires GPIO functionality to be present, it needs to select GPIOLIB from its
Kconfig. Then, how GPIOs are mapped depends on what the platform uses to
describe its hardware layout. Currently, mappings can be defined through device
tree, ACPI, and platform data.

View file

@ -72,8 +72,8 @@ in this document, but drivers acting as clients to the GPIO interface must
not care how it's implemented.)
That said, if the convention is supported on their platform, drivers should
use it when possible. Platforms must select ARCH_REQUIRE_GPIOLIB or
ARCH_WANT_OPTIONAL_GPIOLIB in their Kconfig. Drivers that can't work without
use it when possible. Platforms must select GPIOLIB if GPIO functionality
is strictly required. Drivers that can't work without
standard GPIO calls should have Kconfig entries which depend on GPIOLIB. The
GPIO calls are available, either as "real code" or as optimized-away stubs,
when drivers use the include file:
@ -553,22 +553,14 @@ either NULL or the label associated with that GPIO when it was requested.
Platform Support
----------------
To support this framework, a platform's Kconfig will "select" either
ARCH_REQUIRE_GPIOLIB or ARCH_WANT_OPTIONAL_GPIOLIB
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().
To force-enable this framework, a platform's Kconfig will "select" GPIOLIB,
else it is up to the user to configure support for GPIO.
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.
ARCH_WANT_OPTIONAL_GPIOLIB means the gpiolib code defaults to off and the user
can enable it and build it into the kernel optionally.
If neither of these options are selected, the platform does not support
GPIOs through GPIO-lib and the code cannot be enabled by the user.

View file

@ -10,27 +10,6 @@ config ARCH_HAVE_CUSTOM_GPIO_H
overriding the default implementations. New uses of this are
strongly discouraged.
config ARCH_WANT_OPTIONAL_GPIOLIB
bool
help
Select this config option from the architecture Kconfig, if
it is possible to use gpiolib on the architecture, but let the
user decide whether to actually build it or not.
Select this instead of ARCH_REQUIRE_GPIOLIB, if your architecture does
not depend on GPIOs being available, but rather let the user
decide whether he needs it or not.
config ARCH_REQUIRE_GPIOLIB
bool
select GPIOLIB
help
Platforms select gpiolib if they use this infrastructure
for all their GPIOs, usually starting with ones integrated
into SOC processors.
Selecting this from the architecture code will cause the gpiolib
code to always get built in.
menuconfig GPIOLIB
bool "GPIO Support"
select ANON_INODES