[RFC 00/17] Remove GENERIC_GPIO from architecture code

From: Alexandre Courbot
Date: Tue Mar 12 2013 - 06:17:52 EST


This series makes sure the GENERIC_GPIO option can only be set through GPIOLIB
(and not by individual architectures), as a first step towards its removal.

It is targeted at getting feedback from architecture maintainers (and complains
if this is deemed too bold a move - however, I hope the rationale behind this
will be convincing).

AFAICT every GPIO driver that implement the generic GPIO API support gpiolib at
least optionally, and the overwhelming majority actually requires it. Using the
generic GPIO API alone has become a marginal practice, and the benefit of
retaining this option is rather uncertain when compared to the confusion and
complexity it induces:
* More and more GPIO features are built around gpiolib. The sysfs interface is
one of them ; the future gpiod API is another one. Platforms that only implement
the generic GPIO API cannot benefit from these and the split between those who
only implement the generic GPIO API and full-fledge users of gpiolib is becoming
wider and wider.
* Having two layers of GPIO support is confusing to both GPIO users and
providers, and it is easy to e.g. only depend on GENERIC_GPIO when one actually
needs gpiolib. This series actually fixes a few of these cases.
* Simplicity and consistency is always a good thing - features in the kernel are
typically implemented through well-defined frameworks, and similarly GPIO
support could be consolidated around gpiolib.

Arguments against using gpiolib:
* Memory footprint of gpiolib. According to my tests a gpiolib with 256 GPIOs
induces an overhead of ~15KB, which sounds rather reasonable.
* Performance. gpiolib introduces another layer of indirection compared to
drivers that only implement the generic GPIO API. However, a fast path is
available to platforms for which GPIO performance matters through the
implementation of custom gpio_set_value() and gpio_get_value() functions which
test for a given GPIO range and shortcut gpiolib.

For most platforms, this change should be a no-op. However I would like to make
sure that everyone is ok with it and that nothing gets broken, as the effect of
changing configuration options are sometimes difficult to predict.

Alexandre Courbot (17):
arm: remove unneeded select GENERIC_GPIO
arm: remove redundant GENERIC_GPIO selection
arm: plat-orion: use GPIO driver on CONFIG_GPIOLIB
mips: remove redundant GENERIC_GPIO select
mips: loongson: use GPIO driver on CONFIG_GPIOLIB
mips: txx9: change GENERIC_GPIO to GPIOLIB
unicore32: remove unneeded select GENERIC_GPIO
powerpc: remove redundant GENERIC_GPIO selection
sh: replace CONFIG_GENERIC_GPIO by CONFIG_GPIOLIB
xtensa: remove explicit selection of GENERIC_GPIO
mips: alchemy: require gpiolib
mips: pnx833x: remove requirement for GENERIC_GPIO
avr32: default GENERIC_GPIO to false
m68k: coldfire: use gpiolib
avr32: default GENERIC_GPIO to false
openrisc: default GENERIC_GPIO to false
unicore32: default GENERIC_GPIO to false

arch/arm/Kconfig | 2 --
arch/arm/plat-orion/Makefile | 2 +-
arch/avr32/Kconfig | 2 +-
arch/blackfin/Kconfig | 2 +-
arch/m68k/Kconfig.cpu | 3 +--
arch/mips/Kconfig | 7 +------
arch/mips/loongson/common/Makefile | 2 +-
arch/mips/txx9/generic/setup.c | 2 +-
arch/openrisc/Kconfig | 2 +-
arch/powerpc/platforms/40x/Kconfig | 1 -
arch/powerpc/platforms/44x/Kconfig | 1 -
arch/powerpc/platforms/85xx/Kconfig | 1 -
arch/powerpc/platforms/86xx/Kconfig | 3 ---
arch/powerpc/platforms/8xx/Kconfig | 1 -
arch/powerpc/platforms/Kconfig | 4 ----
arch/sh/boards/mach-sdk7786/Makefile | 2 +-
arch/sh/boards/mach-x3proto/Makefile | 2 +-
arch/sh/kernel/cpu/sh2a/Makefile | 2 +-
arch/sh/kernel/cpu/sh3/Makefile | 2 +-
arch/sh/kernel/cpu/sh4a/Makefile | 2 +-
arch/unicore32/Kconfig | 3 +--
arch/xtensa/configs/iss_defconfig | 1 -
arch/xtensa/configs/s6105_defconfig | 1 -
23 files changed, 14 insertions(+), 36 deletions(-)

--
1.8.1.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/