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
Remove the selection of GENERIC_GPIO for S3C24XX and S5PC100 in
preparation of the removal of this option.
ARCH_REQUIRE_GPIOLIB (which also selects GENERIC_GPIO) is already
selected whenever these machines are chosen anyway, so this
patch should not have any side-effect.
Signed-off-by: Alexandre Courbot <[email protected]>
---
arch/arm/Kconfig | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ad06749..26b6ddd 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -773,7 +773,6 @@ config ARCH_S3C24XX
select CLKDEV_LOOKUP
select CLKSRC_MMIO
select GENERIC_CLOCKEVENTS
- select GENERIC_GPIO
select HAVE_CLK
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C2410_WATCHDOG if WATCHDOG
@@ -832,7 +831,6 @@ config ARCH_S5PC100
select CLKSRC_MMIO
select CPU_V7
select GENERIC_CLOCKEVENTS
- select GENERIC_GPIO
select HAVE_CLK
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C2410_WATCHDOG if WATCHDOG
--
1.8.1.5
The GPIO driver uses gpiolib, thus it should be compiled when
CONFIG_GPIOLIB is defined and not only CONFIG_GENERIC_GPIO
Signed-off-by: Alexandre Courbot <[email protected]>
---
arch/arm/plat-orion/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/plat-orion/Makefile b/arch/arm/plat-orion/Makefile
index a82cecb..bbc0d6b 100644
--- a/arch/arm/plat-orion/Makefile
+++ b/arch/arm/plat-orion/Makefile
@@ -5,6 +5,6 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include
obj-y += addr-map.o
-orion-gpio-$(CONFIG_GENERIC_GPIO) += gpio.o
+orion-gpio-$(CONFIG_GPIOLIB) += gpio.o
obj-$(CONFIG_PLAT_ORION_LEGACY) += irq.o pcie.o time.o common.o mpp.o
obj-$(CONFIG_PLAT_ORION_LEGACY) += $(orion-gpio-y)
--
1.8.1.5
Signed-off-by: Alexandre Courbot <[email protected]>
---
arch/mips/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index b7b7228..ae70ab1 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -1199,7 +1199,6 @@ config CPU_LOONGSON2F
bool "Loongson 2F"
depends on SYS_HAS_CPU_LOONGSON2F
select CPU_LOONGSON2
- select GENERIC_GPIO
select ARCH_REQUIRE_GPIOLIB
help
The Loongson 2F processor implements the MIPS III instruction set
--
1.8.1.5
The GPIO driver uses gpiolib, thus it should be compiled when
CONFIG_GPIOLIB is defined and not only CONFIG_GENERIC_GPIO.
Signed-off-by: Alexandre Courbot <[email protected]>
---
arch/mips/loongson/common/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/loongson/common/Makefile b/arch/mips/loongson/common/Makefile
index e526488..4c57b3e 100644
--- a/arch/mips/loongson/common/Makefile
+++ b/arch/mips/loongson/common/Makefile
@@ -4,7 +4,7 @@
obj-y += setup.o init.o cmdline.o env.o time.o reset.o irq.o \
pci.o bonito-irq.o mem.o machtype.o platform.o
-obj-$(CONFIG_GENERIC_GPIO) += gpio.o
+obj-$(CONFIG_GPIOLIB) += gpio.o
#
# Serial port support
--
1.8.1.5
PUV3_GPIO depends on ARCH_PUV3 which requires GPIOLIB and thus already
selects GENERIC_GPIO
Signed-off-by: Alexandre Courbot <[email protected]>
---
arch/unicore32/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/unicore32/Kconfig b/arch/unicore32/Kconfig
index dc50b15..a889117 100644
--- a/arch/unicore32/Kconfig
+++ b/arch/unicore32/Kconfig
@@ -219,7 +219,6 @@ if ARCH_PUV3
config PUV3_GPIO
bool
depends on !ARCH_FPGA
- select GENERIC_GPIO
select GPIO_SYSFS
default y
--
1.8.1.5
GENERIC_GPIO was explicitly selected along with ARCH_REQUIRE_GPIOLIB,
which itself selects GENERIC_GPIO.
Signed-off-by: Alexandre Courbot <[email protected]>
---
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 ----
6 files changed, 11 deletions(-)
diff --git a/arch/powerpc/platforms/40x/Kconfig b/arch/powerpc/platforms/40x/Kconfig
index a392d12..d0b46a2 100644
--- a/arch/powerpc/platforms/40x/Kconfig
+++ b/arch/powerpc/platforms/40x/Kconfig
@@ -145,7 +145,6 @@ config PPC4xx_GPIO
bool "PPC4xx GPIO support"
depends on 40x
select ARCH_REQUIRE_GPIOLIB
- select GENERIC_GPIO
help
Enable gpiolib support for ppc40x based boards
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index 0effe9f..50306b8 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -248,7 +248,6 @@ config PPC4xx_GPIO
bool "PPC4xx GPIO support"
depends on 44x
select ARCH_REQUIRE_GPIOLIB
- select GENERIC_GPIO
help
Enable gpiolib support for ppc440 based boards
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index a0dcd57..78549b6 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -203,7 +203,6 @@ config GE_IMP3A
select DEFAULT_UIMAGE
select SWIOTLB
select MMIO_NVRAM
- select GENERIC_GPIO
select ARCH_REQUIRE_GPIOLIB
select GE_FPGA
help
diff --git a/arch/powerpc/platforms/86xx/Kconfig b/arch/powerpc/platforms/86xx/Kconfig
index 7a6279e..1afd1e4 100644
--- a/arch/powerpc/platforms/86xx/Kconfig
+++ b/arch/powerpc/platforms/86xx/Kconfig
@@ -37,7 +37,6 @@ config GEF_PPC9A
bool "GE PPC9A"
select DEFAULT_UIMAGE
select MMIO_NVRAM
- select GENERIC_GPIO
select ARCH_REQUIRE_GPIOLIB
select GE_FPGA
help
@@ -47,7 +46,6 @@ config GEF_SBC310
bool "GE SBC310"
select DEFAULT_UIMAGE
select MMIO_NVRAM
- select GENERIC_GPIO
select ARCH_REQUIRE_GPIOLIB
select GE_FPGA
help
@@ -57,7 +55,6 @@ config GEF_SBC610
bool "GE SBC610"
select DEFAULT_UIMAGE
select MMIO_NVRAM
- select GENERIC_GPIO
select ARCH_REQUIRE_GPIOLIB
select GE_FPGA
select HAS_RAPIDIO
diff --git a/arch/powerpc/platforms/8xx/Kconfig b/arch/powerpc/platforms/8xx/Kconfig
index 1fb0b3c..8dec3c0 100644
--- a/arch/powerpc/platforms/8xx/Kconfig
+++ b/arch/powerpc/platforms/8xx/Kconfig
@@ -114,7 +114,6 @@ config 8xx_COPYBACK
config 8xx_GPIO
bool "GPIO API Support"
- select GENERIC_GPIO
select ARCH_REQUIRE_GPIOLIB
help
Saying Y here will cause the ports on an MPC8xx processor to be used
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index 52de8bc..15095d5 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -303,7 +303,6 @@ config QUICC_ENGINE
config QE_GPIO
bool "QE GPIO support"
depends on QUICC_ENGINE
- select GENERIC_GPIO
select ARCH_REQUIRE_GPIOLIB
help
Say Y here if you're going to use hardware that connects to the
@@ -316,7 +315,6 @@ config CPM2
select PPC_LIB_RHEAP
select PPC_PCI_CHOICE
select ARCH_REQUIRE_GPIOLIB
- select GENERIC_GPIO
help
The CPM2 (Communications Processor Module) is a coprocessor on
embedded CPUs made by Freescale. Selecting this option means that
@@ -355,7 +353,6 @@ config OF_RTC
config SIMPLE_GPIO
bool "Support for simple, memory-mapped GPIO controllers"
depends on PPC
- select GENERIC_GPIO
select ARCH_REQUIRE_GPIOLIB
help
Say Y here to support simple, memory-mapped GPIO controllers.
@@ -366,7 +363,6 @@ config SIMPLE_GPIO
config MCU_MPC8349EMITX
bool "MPC8349E-mITX MCU driver"
depends on I2C=y && PPC_83xx
- select GENERIC_GPIO
select ARCH_REQUIRE_GPIOLIB
help
Say Y here to enable soft power-off functionality on the Freescale
--
1.8.1.5
The GPIO driver for txx9 requires gpiolib, so this is more accurate and
let us get rid of one mention of GENERIC_GPIO which is due to disappear.
Signed-off-by: Alexandre Courbot <[email protected]>
---
arch/mips/txx9/generic/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/txx9/generic/setup.c b/arch/mips/txx9/generic/setup.c
index 5524f2c..5364aab 100644
--- a/arch/mips/txx9/generic/setup.c
+++ b/arch/mips/txx9/generic/setup.c
@@ -118,7 +118,7 @@ EXPORT_SYMBOL(clk_put);
/* GPIO support */
-#ifdef CONFIG_GENERIC_GPIO
+#ifdef CONFIG_GPIOLIB
int gpio_to_irq(unsigned gpio)
{
return -EINVAL;
--
1.8.1.5
pnx833x does not seem to use the generic gpio API.
Signed-off-by: Alexandre Courbot <[email protected]>
---
arch/mips/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 5cfa818..c1c6549 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -1107,7 +1107,6 @@ config SOC_PNX833X
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_LITTLE_ENDIAN
select SYS_SUPPORTS_BIG_ENDIAN
- select GENERIC_GPIO
select CPU_MIPSR2_IRQ_VI
config SOC_PNX8335
--
1.8.1.5
Require gpiolib instead of just GENERIC_GPIO.
Signed-off-by: Alexandre Courbot <[email protected]>
---
arch/mips/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index ae70ab1..5cfa818 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -61,8 +61,7 @@ config MIPS_ALCHEMY
select SYS_HAS_CPU_MIPS32_R1
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_APM_EMULATION
- select GENERIC_GPIO
- select ARCH_WANT_OPTIONAL_GPIOLIB
+ select ARCH_REQUIRE_GPIOLIB
select SYS_SUPPORTS_ZBOOT
select USB_ARCH_HAS_OHCI
select USB_ARCH_HAS_EHCI
--
1.8.1.5
This will help removing the GENERIC_GPIO option.
GPIO access is done through gpiolib, which selects GENERIC_GPIO anyway.
Signed-off-by: Alexandre Courbot <[email protected]>
---
arch/avr32/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/avr32/Kconfig b/arch/avr32/Kconfig
index 9b89257..85c377e 100644
--- a/arch/avr32/Kconfig
+++ b/arch/avr32/Kconfig
@@ -27,7 +27,7 @@ config AVR32
http://avr32linux.org/.
config GENERIC_GPIO
- def_bool y
+ def_bool n
config STACKTRACE_SUPPORT
def_bool y
--
1.8.1.5
Force use of gpiolib for Coldfire, as a step towards the deprecation of
GENERIC_GPIO.
Signed-off-by: Alexandre Courbot <[email protected]>
---
arch/m68k/Kconfig.cpu | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu
index b1cfff8..d266787 100644
--- a/arch/m68k/Kconfig.cpu
+++ b/arch/m68k/Kconfig.cpu
@@ -22,8 +22,7 @@ config M68KCLASSIC
config COLDFIRE
bool "Coldfire CPU family support"
- select GENERIC_GPIO
- select ARCH_WANT_OPTIONAL_GPIOLIB
+ select ARCH_REQUIRE_GPIOLIB
select ARCH_HAVE_CUSTOM_GPIO_H
select CPU_HAS_NO_BITFIELDS
select CPU_HAS_NO_MULDIV64
--
1.8.1.5
Signed-off-by: Alexandre Courbot <[email protected]>
---
arch/blackfin/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig
index 600494c..b947e26 100644
--- a/arch/blackfin/Kconfig
+++ b/arch/blackfin/Kconfig
@@ -56,7 +56,7 @@ config ZONE_DMA
def_bool y
config GENERIC_GPIO
- def_bool y
+ def_bool n
config FORCE_MAX_ZONEORDER
int
--
1.8.1.5
This is one step towards the removal of the GENERIC_GPIO option.
OpenRISC mandates the use of GPIOLIB, which enables GENERIC_GPIO anyway,
so this patch should be a no-op.
Signed-off-by: Alexandre Courbot <[email protected]>
---
arch/openrisc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/openrisc/Kconfig b/arch/openrisc/Kconfig
index 28df179..5366bbf 100644
--- a/arch/openrisc/Kconfig
+++ b/arch/openrisc/Kconfig
@@ -46,7 +46,7 @@ config NO_IOPORT
def_bool y
config GENERIC_GPIO
- def_bool y
+ def_bool n
config TRACE_IRQFLAGS_SUPPORT
def_bool y
--
1.8.1.5
GPIO implementation for unicore32 uses gpiolib, which sets GENERIC_GPIO
when selected.
Signed-off-by: Alexandre Courbot <[email protected]>
---
arch/unicore32/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/unicore32/Kconfig b/arch/unicore32/Kconfig
index a889117..9bb1180 100644
--- a/arch/unicore32/Kconfig
+++ b/arch/unicore32/Kconfig
@@ -24,7 +24,7 @@ config UNICORE32
Please see web page at <http://www.pkunity.com/>.
config GENERIC_GPIO
- def_bool y
+ def_bool n
config GENERIC_CSUM
def_bool y
--
1.8.1.5
SH GPIO drivers all use gpiolib and CONFIG_GENERIC_GPIO is only selected
through CONFIG_GPIOLIB, yet some compilation units depended on
CONFIG_GENERIC_GPIO. Make them depend on CONFIG_GPIOLIB instead since it
is more accurate and prepares us for the future removal of
CONFIG_GENERIC_GPIO.
Signed-off-by: Alexandre Courbot <[email protected]>
---
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 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/sh/boards/mach-sdk7786/Makefile b/arch/sh/boards/mach-sdk7786/Makefile
index 8ae56e9..45d32e3 100644
--- a/arch/sh/boards/mach-sdk7786/Makefile
+++ b/arch/sh/boards/mach-sdk7786/Makefile
@@ -1,4 +1,4 @@
obj-y := fpga.o irq.o nmi.o setup.o
-obj-$(CONFIG_GENERIC_GPIO) += gpio.o
+obj-$(CONFIG_GPIOLIB) += gpio.o
obj-$(CONFIG_HAVE_SRAM_POOL) += sram.o
diff --git a/arch/sh/boards/mach-x3proto/Makefile b/arch/sh/boards/mach-x3proto/Makefile
index 708c21c..0cbe3d0 100644
--- a/arch/sh/boards/mach-x3proto/Makefile
+++ b/arch/sh/boards/mach-x3proto/Makefile
@@ -1,3 +1,3 @@
obj-y += setup.o ilsel.o
-obj-$(CONFIG_GENERIC_GPIO) += gpio.o
+obj-$(CONFIG_GPIOLIB) += gpio.o
diff --git a/arch/sh/kernel/cpu/sh2a/Makefile b/arch/sh/kernel/cpu/sh2a/Makefile
index 130984c..92f0da4 100644
--- a/arch/sh/kernel/cpu/sh2a/Makefile
+++ b/arch/sh/kernel/cpu/sh2a/Makefile
@@ -21,5 +21,5 @@ pinmux-$(CONFIG_CPU_SUBTYPE_SH7203) := pinmux-sh7203.o
pinmux-$(CONFIG_CPU_SUBTYPE_SH7264) := pinmux-sh7264.o
pinmux-$(CONFIG_CPU_SUBTYPE_SH7269) := pinmux-sh7269.o
-obj-$(CONFIG_GENERIC_GPIO) += $(pinmux-y)
+obj-$(CONFIG_GPIOLIB) += $(pinmux-y)
obj-$(CONFIG_HAVE_HW_BREAKPOINT) += ubc.o
diff --git a/arch/sh/kernel/cpu/sh3/Makefile b/arch/sh/kernel/cpu/sh3/Makefile
index 6f13f33..d3634ae 100644
--- a/arch/sh/kernel/cpu/sh3/Makefile
+++ b/arch/sh/kernel/cpu/sh3/Makefile
@@ -30,4 +30,4 @@ clock-$(CONFIG_CPU_SUBTYPE_SH7712) := clock-sh7712.o
pinmux-$(CONFIG_CPU_SUBTYPE_SH7720) := pinmux-sh7720.o
obj-y += $(clock-y)
-obj-$(CONFIG_GENERIC_GPIO) += $(pinmux-y)
+obj-$(CONFIG_GPIOLIB) += $(pinmux-y)
diff --git a/arch/sh/kernel/cpu/sh4a/Makefile b/arch/sh/kernel/cpu/sh4a/Makefile
index 8fc6ec2..0705df7 100644
--- a/arch/sh/kernel/cpu/sh4a/Makefile
+++ b/arch/sh/kernel/cpu/sh4a/Makefile
@@ -47,6 +47,6 @@ pinmux-$(CONFIG_CPU_SUBTYPE_SHX3) := pinmux-shx3.o
obj-y += $(clock-y)
obj-$(CONFIG_SMP) += $(smp-y)
-obj-$(CONFIG_GENERIC_GPIO) += $(pinmux-y)
+obj-$(CONFIG_GPIOLIB) += $(pinmux-y)
obj-$(CONFIG_PERF_EVENTS) += perf_event.o
obj-$(CONFIG_HAVE_HW_BREAKPOINT) += ubc.o
--
1.8.1.5
The Xtensa GPIO driver uses gpiolib and cannot compile with only
GENERIC_GPIO.
Signed-off-by: Alexandre Courbot <[email protected]>
---
arch/xtensa/configs/iss_defconfig | 1 -
arch/xtensa/configs/s6105_defconfig | 1 -
2 files changed, 2 deletions(-)
diff --git a/arch/xtensa/configs/iss_defconfig b/arch/xtensa/configs/iss_defconfig
index ddab37b..77c52f8 100644
--- a/arch/xtensa/configs/iss_defconfig
+++ b/arch/xtensa/configs/iss_defconfig
@@ -10,7 +10,6 @@ CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_HARDIRQS=y
-CONFIG_GENERIC_GPIO=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_NO_IOPORT=y
diff --git a/arch/xtensa/configs/s6105_defconfig b/arch/xtensa/configs/s6105_defconfig
index eaf1b8f..4799c6a 100644
--- a/arch/xtensa/configs/s6105_defconfig
+++ b/arch/xtensa/configs/s6105_defconfig
@@ -10,7 +10,6 @@ CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_HARDIRQS=y
-CONFIG_GENERIC_GPIO=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_NO_IOPORT=y
--
1.8.1.5
GENERIC_GPIO was selected next to ARCH_REQUIRE_GPIOLIB, which itself
selects GENERIC_GPIO.
Signed-off-by: Alexandre Courbot <[email protected]>
---
arch/mips/Kconfig | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 32eb3d6..b7b7228 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -225,7 +225,6 @@ config MACH_JZ4740
select SYS_SUPPORTS_ZBOOT_UART16550
select DMA_NONCOHERENT
select IRQ_CPU
- select GENERIC_GPIO
select ARCH_REQUIRE_GPIOLIB
select SYS_HAS_EARLY_PRINTK
select HAVE_PWM
@@ -935,7 +934,6 @@ config CSRC_SB1250
bool
config GPIO_TXX9
- select GENERIC_GPIO
select ARCH_REQUIRE_GPIOLIB
bool
--
1.8.1.5
On Tue, Mar 12, 2013 at 07:12:22PM +0900, Alexandre Courbot wrote:
> SH GPIO drivers all use gpiolib and CONFIG_GENERIC_GPIO is only selected
> through CONFIG_GPIOLIB, yet some compilation units depended on
> CONFIG_GENERIC_GPIO. Make them depend on CONFIG_GPIOLIB instead since it
> is more accurate and prepares us for the future removal of
> CONFIG_GENERIC_GPIO.
>
> Signed-off-by: Alexandre Courbot <[email protected]>
Note that the bulk of the GENERIC_GPIO use for SH has shifted to
drivers/pinctrl/sh-pfc/. If GPIOLIB is forced then a good chunk of the
Kconfig/Makefile bits there ought to be refactored too.
On 03/12/2013 07:35 PM, Paul Mundt wrote:
> On Tue, Mar 12, 2013 at 07:12:22PM +0900, Alexandre Courbot wrote:
>> SH GPIO drivers all use gpiolib and CONFIG_GENERIC_GPIO is only selected
>> through CONFIG_GPIOLIB, yet some compilation units depended on
>> CONFIG_GENERIC_GPIO. Make them depend on CONFIG_GPIOLIB instead since it
>> is more accurate and prepares us for the future removal of
>> CONFIG_GENERIC_GPIO.
>>
>> Signed-off-by: Alexandre Courbot <[email protected]>
>
> Note that the bulk of the GENERIC_GPIO use for SH has shifted to
> drivers/pinctrl/sh-pfc/. If GPIOLIB is forced then a good chunk of the
> Kconfig/Makefile bits there ought to be refactored too.
Yes, that is the case for many other drivers actually. This series just
makes sure that GENERIC_GPIO is set through GPIOLIB *only*, thus making
both options equivalent. If nobody shoots me for this, I will refactor
individual drivers and ultimately remove GENERIC_GPIO completely.
Alex.
On Tue, Mar 12, 2013 at 07:43:43PM +0900, Alex Courbot wrote:
> On 03/12/2013 07:35 PM, Paul Mundt wrote:
> >On Tue, Mar 12, 2013 at 07:12:22PM +0900, Alexandre Courbot wrote:
> >>SH GPIO drivers all use gpiolib and CONFIG_GENERIC_GPIO is only selected
> >>through CONFIG_GPIOLIB, yet some compilation units depended on
> >>CONFIG_GENERIC_GPIO. Make them depend on CONFIG_GPIOLIB instead since it
> >>is more accurate and prepares us for the future removal of
> >>CONFIG_GENERIC_GPIO.
> >>
> >>Signed-off-by: Alexandre Courbot <[email protected]>
> >
> >Note that the bulk of the GENERIC_GPIO use for SH has shifted to
> >drivers/pinctrl/sh-pfc/. If GPIOLIB is forced then a good chunk of the
> >Kconfig/Makefile bits there ought to be refactored too.
>
> Yes, that is the case for many other drivers actually. This series
> just makes sure that GENERIC_GPIO is set through GPIOLIB *only*,
> thus making both options equivalent. If nobody shoots me for this, I
> will refactor individual drivers and ultimately remove GENERIC_GPIO
> completely.
>
Ok, just wanted to make sure you were aware of this. I don't have any
strong opinions on this one way or the other, the entire GPIO Kconfig
mess is too ugly for words, so any effort to clean that up is probably
worth the added bloat.
Acked-by: Paul Mundt <[email protected]>
On Tuesday 12 March 2013, Alexandre Courbot wrote:
> @@ -24,7 +24,7 @@ config UNICORE32
> Please see web page at <http://www.pkunity.com/>.
>
> config GENERIC_GPIO
> - def_bool y
> + def_bool n
>
"def_bool n" is the same as "bool", but in general the latter syntax is preferred.
Arnd
On Tuesday 12 March 2013, Alexandre Courbot wrote:
>
> 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.
>
Nice series,
Acked-by: Arnd Bergmann <[email protected]>
> 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.
It's probably worth pointing out which platforms actually change with this. For
all I can tell, the only user-visible change is that m68k now cannot turn
off gpiolib any more.
Arnd
On Tuesday 12 March 2013, Alexandre Courbot wrote:
> Thanks, I will fix this in the next version.
>
> Btw, if this (or rather the next iteration) gets merged, may I suggest to
> do it through the GPIO tree instead of having each architecture picking the
> patches of relevance. A considerable number of other patches that depend on
> this will follow and this will ensure they are picked in the right order.
Sounds reasonable, but I would also suggest you prepare a branch that can
get merged into the GPIO, ARM, PowerPC and MIPS trees to avoid merge
conflicts in that case, since these all will have a number of changes
conflicting with yours.
In the end, I would not care which tree it gets merged through, as long
as all have the same version of your patches.
Arnd
Around Tue 12 Mar 2013 19:12:28 +0900 or thereabout, Alexandre Courbot wrote:
$(Subject) is wrong, you state avr32, but it is for blackfin.
> Signed-off-by: Alexandre Courbot <[email protected]>
> ---
> arch/blackfin/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig
> index 600494c..b947e26 100644
> --- a/arch/blackfin/Kconfig
> +++ b/arch/blackfin/Kconfig
> @@ -56,7 +56,7 @@ config ZONE_DMA
> def_bool y
>
> config GENERIC_GPIO
> - def_bool y
> + def_bool n
>
> config FORCE_MAX_ZONEORDER
> int
--
mvh
Hans-Christian Egtvedt
On Tue, Mar 12, 2013 at 9:55 PM, Hans-Christian Egtvedt
<[email protected]> wrote:
> Around Tue 12 Mar 2013 19:12:28 +0900 or thereabout, Alexandre Courbot wrote:
>
> $(Subject) is wrong, you state avr32, but it is for blackfin.
Argh, apologies. That's very wrong, especially since blackfin is one
of the archs most affected by this. Thanks for catching this, I hope
the maintainers will notice it too.
Alex.
On Tue, Mar 12, 2013 at 8:18 PM, Arnd Bergmann <[email protected]> wrote:
> On Tuesday 12 March 2013, Alexandre Courbot wrote:
>> @@ -24,7 +24,7 @@ config UNICORE32
>> Please see web page at <http://www.pkunity.com/>.
>>
>> config GENERIC_GPIO
>> - def_bool y
>> + def_bool n
>>
>
> "def_bool n" is the same as "bool", but in general the latter syntax is preferred.
I have fixed this for unicore32, but a few other architectures use the
"def_bool n" syntax consistently across their Kconfig, so for
consistency reasons it is maybe preferable to leave it that way for
them.
Alex.
On Tue, Mar 12, 2013 at 8:23 PM, Arnd Bergmann <[email protected]> wrote:
> Nice series,
>
> Acked-by: Arnd Bergmann <[email protected]>
Thanks!
>> 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.
>
> It's probably worth pointing out which platforms actually change with this. For
> all I can tell, the only user-visible change is that m68k now cannot turn
> off gpiolib any more.
That's the one we are sure is affected indeed. I am also a little bit
worried about blackfin, since it used to compile with GENERIC_GPIO and
patch #15 removes that. However it seems that blackfin's GPIO driver
is unconditionally compiled, so the whole architecture might actually
need ARCH_REQUIRE_GPIOLIB now.
There are also some more subtle changes in mips and arm where I rely
on indirect selection of gpiolib to assume that GENERIC_GPIO will
remain true - it's a bit of a headache, actually. Anyway the arch
maintainers know better what they really need, so I prefer not to
assume too much on my own.
Alex.
On Tuesday 12 March 2013, Alexandre Courbot wrote:
> I have fixed this for unicore32, but a few other architectures use the
> "def_bool n" syntax consistently across their Kconfig, so for
> consistency reasons it is maybe preferable to leave it that way for
> them.
Ok, fair enough.
Arnd
On Tue, Mar 12, 2013 at 11:12 AM, Alexandre Courbot <[email protected]> wrote:
> 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.
Nice!
Acked-by: Linus Walleij <[email protected]>
I bet something will break, anyway: no pain no gain.
Yours,
Linus Walleij
On 03/12/13 11:12, Alexandre Courbot wrote:
> This is one step towards the removal of the GENERIC_GPIO option.
> OpenRISC mandates the use of GPIOLIB, which enables GENERIC_GPIO anyway,
> so this patch should be a no-op.
Acked-by: Jonas Bonn <[email protected]>
> Signed-off-by: Alexandre Courbot <[email protected]>
> ---
> arch/openrisc/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/openrisc/Kconfig b/arch/openrisc/Kconfig
> index 28df179..5366bbf 100644
> --- a/arch/openrisc/Kconfig
> +++ b/arch/openrisc/Kconfig
> @@ -46,7 +46,7 @@ config NO_IOPORT
> def_bool y
>
> config GENERIC_GPIO
> - def_bool y
> + def_bool n
>
> config TRACE_IRQFLAGS_SUPPORT
> def_bool y
On Wed, Mar 13, 2013 at 1:12 PM, Linus Walleij <[email protected]> wrote:
> On Tue, Mar 12, 2013 at 11:12 AM, Alexandre Courbot <[email protected]> wrote:
>
>> 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.
>
> Nice!
> Acked-by: Linus Walleij <[email protected]>
>
> I bet something will break, anyway: no pain no gain.
Since this is a pretty invasive patch series that touches a lot of
architectures, we should get it into a separate branch that can get
pulled into linux-next.
g.
On Wed, Mar 13, 2013 at 8:53 AM, Grant Likely <[email protected]> wrote:
> On Wed, Mar 13, 2013 at 1:12 PM, Linus Walleij <[email protected]> wrote:
>> On Tue, Mar 12, 2013 at 11:12 AM, Alexandre Courbot <[email protected]> wrote:
>>
>>> 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.
>>
>> Nice!
>> Acked-by: Linus Walleij <[email protected]>
>>
>> I bet something will break, anyway: no pain no gain.
>
> Since this is a pretty invasive patch series that touches a lot of
> architectures, we should get it into a separate branch that can get
> pulled into linux-next.
Good point. Alexandre, do you have a git repo to attain this?
Yours,
Linus Walleij
On Thu, Mar 14, 2013 at 3:01 AM, Linus Walleij <[email protected]> wrote:
> On Wed, Mar 13, 2013 at 8:53 AM, Grant Likely <[email protected]> wrote:
>> On Wed, Mar 13, 2013 at 1:12 PM, Linus Walleij <[email protected]> wrote:
>>> On Tue, Mar 12, 2013 at 11:12 AM, Alexandre Courbot <[email protected]> wrote:
>>>
>>>> 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.
>>>
>>> Nice!
>>> Acked-by: Linus Walleij <[email protected]>
>>>
>>> I bet something will break, anyway: no pain no gain.
>>
>> Since this is a pretty invasive patch series that touches a lot of
>> architectures, we should get it into a separate branch that can get
>> pulled into linux-next.
>
> Good point. Alexandre, do you have a git repo to attain this?
Would be reasonable indeed. I can publish the branch on Github, but
(sorry for being clueless) what's the procedure to add a new branch to
linux-next? Shall I write to Stephen Rothwell directly?
Alex.
On Thu, Mar 14, 2013 at 3:08 PM, Alexandre Courbot <[email protected]> wrote:
> Would be reasonable indeed. I can publish the branch on Github,
That'll work.
For submitting the pull request to Torvalds in the end you will need
to create a signed tag. Do you have a signed GPG key? Else it's
about time to create a key and start collecting signatures... then you
can also get a repo at kernel.org in the future.
> but
> (sorry for being clueless) what's the procedure to add a new branch to
> linux-next? Shall I write to Stephen Rothwell directly?
Yes. Join the linux-next mailing list too.
Yours,
Linus Walleij
On Thu, Mar 14, 2013 at 11:14 PM, Linus Walleij
<[email protected]> wrote:
> For submitting the pull request to Torvalds in the end you will need
> to create a signed tag. Do you have a signed GPG key? Else it's
> about time to create a key and start collecting signatures... then you
> can also get a repo at kernel.org in the future.
I have one or two signatures of kernel devs on my GPG key, but I
thought that maybe this set could be pulled by you or Grant once it
has undergone enough testing - it's not like I intend to push
regularly on this branch.
If I understand correctly the reason for having this in its own branch
is to be able remove it quickly would it attempt to screw the dog.
>> (sorry for being clueless) what's the procedure to add a new branch to
>> linux-next? Shall I write to Stephen Rothwell directly?
>
> Yes. Join the linux-next mailing list too.
Will do that, thanks. First of all let me send the relevant patches
again to blackfin and m68k and get some feedback from them, since they
are the most affected.
Alex.
On Thursday 14 March 2013, Alexandre Courbot wrote:
>
> On Thu, Mar 14, 2013 at 11:14 PM, Linus Walleij
> <[email protected]> wrote:
> > For submitting the pull request to Torvalds in the end you will need
> > to create a signed tag. Do you have a signed GPG key? Else it's
> > about time to create a key and start collecting signatures... then you
> > can also get a repo at kernel.org in the future.
>
> I have one or two signatures of kernel devs on my GPG key, but I
> thought that maybe this set could be pulled by you or Grant once it
> has undergone enough testing - it's not like I intend to push
> regularly on this branch.
>
> If I understand correctly the reason for having this in its own branch
> is to be able remove it quickly would it attempt to screw the dog.
The main reason I think is so that branch can be pulled by other
people that don't want to pull in all of the other gpio changes.
It could still just be another branch in the existing gpio tree,
at least once everyone is happy with the state of the patches.
Arnd