Le 17/08/2022 à 19:46, Arnd Bergmann a écrit :

On Tue, Aug 9, 2022 at 12:40 PM Christophe Leroy
[off-list ref] wrote:

quoted

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 <redacted>
---
  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

This list should be kept sorted, otherwise you still get e.g. the '264' default
value. If you have a GPIO extender that provides hardcoded GPIO
numbers on your machine, there should be a configuration option for
that driver.

I don't want to change the behaviour for existing configurations. If the 
unconditional default goes before conditional ones, then all following 
defaults will be ignored and you'll get 512 instead of 264 if MAC_H4700 
is selected for instance.

At the time being, you get 0 only when no other default was selected, 
then that 0 implies 512 in asm-generic/gpio.h by:

#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

Which driver is it that needs extra hardcoded GPIO numbers for you?
Have you tried converting it to use GPIO descriptors so you don't
need the number assignment?

It is a max7301 (drivers/gpio/gpio-max730x.c) but I can't understand 
what you mean. GPIO descriptors are for consumers, aren't they ?

During boot I get :

[    0.601942] gpiochip_find_base: found new base at 496
[    0.606337] gpiochip_find_base: found new base at 464
[    0.616408] gpiochip_find_base: found new base at 448
[    0.621826] gpiochip_find_base: found new base at 432
[    0.627228] gpiochip_find_base: found new base at 400
[    0.660984] gpiochip_find_base: found new base at 384
[    0.669631] gpiochip_find_base: found new base at 368
[    0.672713] gpiochip_find_base: found new base at 352
[    0.675805] gpiochip_find_base: found new base at 336
[    0.678885] gpiochip_find_base: found new base at 320
[    0.682178] gpiochip_find_base: found new base at 304
[    0.685275] gpiochip_find_base: found new base at 288
[    0.688366] gpiochip_find_base: found new base at 272
[    0.691678] gpiochip_find_base: found new base at 256
[    0.694762] gpiochip_find_base: found new base at 240
[    0.697847] gpiochip_find_base: found new base at 224
[    0.701441] gpiochip_find_base: found new base at 208
[    0.709427] gpiochip_find_base: found new base at 192
[    0.713859] gpiochip_find_base: found new base at 176
[    0.718002] gpiochip_find_base: found new base at 160
[    0.723316] gpiochip_find_base: found new base at 144
[    0.731105] gpiochip_find_base: found new base at 128
[    0.737403] gpiochip_find_base: found new base at 112
[    0.740614] gpiochip_find_base: found new base at 96
[    0.743701] gpiochip_find_base: found new base at 80
[    0.747246] gpiochip_find_base: found new base at 64
[    4.663677] gpiochip_find_base: found new base at 36
[    5.050792] gpiochip_find_base: found new base at 16
[    5.064892] gpiochip_find_base: cannot find free range
[    5.095527] gpiochip_find_base: cannot find free range

gpiochip_find_base() is called for any GPIO driver, by gpiochip_add() / 
gpiochip_add_data_with_key(), and there is the following comment:

	/*
	 * TODO: this allocates a Linux GPIO number base in the global
	 * GPIO numberspace for this chip. In the long run we want to
	 * get *rid* of this numberspace and use only descriptors, but
	 * it may be a pipe dream. It will not happen before we get rid
	 * of the sysfs interface anyways.
	 */

So, what did I miss ?

Thanks
Christophe
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel