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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
