[PATCH] gpio: Allow user to customise maximum number of GPIOs
Christophe Leroy
christophe.leroy at csgroup.eu
Wed Aug 17 10:21:21 PDT 2022
Le 11/08/2022 à 21:57, H. Peter Anvin a écrit :
> On August 9, 2022 3:40:38 AM PDT, Christophe Leroy <christophe.leroy at csgroup.eu> wrote:
>> At the time being, the default maximum number of GPIOs is set to 512
>> and can only get customised via an architecture specific
>> CONFIG_ARCH_NR_GPIO.
>>
>> The maximum number of GPIOs might be dependent on the number of
>> interface boards and is somewhat independent of architecture.
>>
>> Allow the user to select that maximum number outside of any
>> architecture configuration. To enable that, re-define a
>> core CONFIG_ARCH_NR_GPIO for architectures which don't already
>> define one. Guard it with a new hidden CONFIG_ARCH_HAS_NR_GPIO.
>>
>> Only two architectures will need CONFIG_ARCH_HAS_NR_GPIO: x86 and arm.
>>
>> On arm, do like x86 and set 512 as the default instead of 0, that
>> allows simplifying the logic in asm-generic/gpio.h
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
>> ---
>> Documentation/driver-api/gpio/legacy.rst | 2 +-
>> arch/arm/Kconfig | 3 ++-
>> arch/arm/include/asm/gpio.h | 1 -
>> arch/x86/Kconfig | 1 +
>> drivers/gpio/Kconfig | 14 ++++++++++++++
>> include/asm-generic/gpio.h | 6 ------
>> 6 files changed, 18 insertions(+), 9 deletions(-)
>>
>> diff --git a/Documentation/driver-api/gpio/legacy.rst b/Documentation/driver-api/gpio/legacy.rst
>> index 9b12eeb89170..566b06a584cf 100644
>> --- a/Documentation/driver-api/gpio/legacy.rst
>> +++ b/Documentation/driver-api/gpio/legacy.rst
>> @@ -558,7 +558,7 @@ Platform Support
>> 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
>> +It may also provide a custom value for CONFIG_ARCH_NR_GPIO, 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.
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index 53e6a1da9af5..e55b6560fe4f 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -14,6 +14,7 @@ config ARM
>> select ARCH_HAS_KCOV
>> select ARCH_HAS_MEMBARRIER_SYNC_CORE
>> select ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE
>> + select ARCH_HAS_NR_GPIO
>> select ARCH_HAS_PTE_SPECIAL if ARM_LPAE
>> select ARCH_HAS_PHYS_TO_DMA
>> select ARCH_HAS_SETUP_DMA_OPS
>> @@ -1243,7 +1244,7 @@ config ARCH_NR_GPIO
>> default 352 if ARCH_VT8500
>> default 288 if ARCH_ROCKCHIP
>> default 264 if MACH_H4700
>> - default 0
>> + default 512
>> help
>> Maximum number of GPIOs in the system.
>>
>> diff --git a/arch/arm/include/asm/gpio.h b/arch/arm/include/asm/gpio.h
>> index f3bb8a2bf788..4ebbb58f06ea 100644
>> --- a/arch/arm/include/asm/gpio.h
>> +++ b/arch/arm/include/asm/gpio.h
>> @@ -2,7 +2,6 @@
>> #ifndef _ARCH_ARM_GPIO_H
>> #define _ARCH_ARM_GPIO_H
>>
>> -/* Note: this may rely upon the value of ARCH_NR_GPIOS set in mach/gpio.h */
>> #include <asm-generic/gpio.h>
>>
>> /* The trivial gpiolib dispatchers */
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index f9920f1341c8..a8c956abc21e 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -82,6 +82,7 @@ config X86
>> select ARCH_HAS_MEM_ENCRYPT
>> select ARCH_HAS_MEMBARRIER_SYNC_CORE
>> select ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE
>> + select ARCH_HAS_NR_GPIO
>> select ARCH_HAS_PMEM_API if X86_64
>> select ARCH_HAS_PTE_DEVMAP if X86_64
>> select ARCH_HAS_PTE_SPECIAL
>> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
>> index 0642f579196f..250b50ed44e1 100644
>> --- a/drivers/gpio/Kconfig
>> +++ b/drivers/gpio/Kconfig
>> @@ -11,6 +11,9 @@ config ARCH_HAVE_CUSTOM_GPIO_H
>> overriding the default implementations. New uses of this are
>> strongly discouraged.
>>
>> +config ARCH_HAS_NR_GPIO
>> + bool
>> +
>> menuconfig GPIOLIB
>> bool "GPIO Support"
>> help
>> @@ -22,6 +25,17 @@ menuconfig GPIOLIB
>>
>> if GPIOLIB
>>
>> +config ARCH_NR_GPIO
>> + int "Maximum number of GPIOs" if EXPERT
>> + depends on !ARCH_HAS_NR_GPIO
>> + default 512
>> + help
>> + This allows the user to select the maximum number of GPIOs the
>> + kernel must support. When the architecture defines a number
>> + through CONFIG_ARCH_NR_GPIO, that value is taken and the user
>> + cannot change it. Otherwise it defaults to 512 and the user
>> + can change it when CONFIG_EXPERT is set.
>> +
>> config GPIOLIB_FASTPATH_LIMIT
>> int "Maximum number of GPIOs for fast path"
>> range 32 512
>> diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
>> index aea9aee1f3e9..ee090f534ab8 100644
>> --- a/include/asm-generic/gpio.h
>> +++ b/include/asm-generic/gpio.h
>> @@ -24,13 +24,7 @@
>> * actually an estimate of a board-specific value.
>> */
>>
>> -#ifndef ARCH_NR_GPIOS
>> -#if defined(CONFIG_ARCH_NR_GPIO) && CONFIG_ARCH_NR_GPIO > 0
>> #define ARCH_NR_GPIOS CONFIG_ARCH_NR_GPIO
>> -#else
>> -#define ARCH_NR_GPIOS 512
>> -#endif
>> -#endif
>>
>> /*
>> * "valid" GPIO numbers are nonnegative and may be passed to
>
> This seems very odd to me. GPIOs can be, and often are, attached to peripheral buses which means that the *same system* can have anything from none to thousands of gpios ..
Exactly, that's the reason why it needs to be configurable independently
of the architecture.
The required number of GPIOs depends on the number of boards I have in
the system, not on whether it is a x86_64, an arm or a powerpc CPU.
I did this patch because I faced a problem after I added a board in my
powerpc system. At the time being powerpc has the default, while x86_64
has 1024, and I thought that it would be better to get it configurable
rather than hard coding a higher limit on powerpc as done on x86_64 or
several specific ARM systems.
On the long run the best would probably be to have it dynamic, but it
means more changes, I think having it configurable at build time is a
good compromise for the time being, isn't it ?
Thanks
Christophe
More information about the linux-arm-kernel
mailing list