2022-08-29 16:47:03

by Christophe Leroy

[permalink] [raw]
Subject: [PATCH v1 0/8] gpio: Get rid of ARCH_NR_GPIOS (v1)

Since commit 14e85c0e69d5 ("gpio: remove gpio_descs global array")
there is no limitation on the number of GPIOs that can be allocated
in the system since the allocation is fully dynamic.

ARCH_NR_GPIOS is today only used in order to provide downwards
gpiobase allocation from that value, while static allocation is
performed upwards from 0. However that has the disadvantage of
limiting the number of GPIOs that can be registered in the system.

To overcome this limitation without requiring each and every
platform to provide its 'best-guess' maximum number, rework the
allocation to allocate from 256 upwards, allowing approx 2 millions
of GPIOs.

In the meantime, add a warning for drivers how are still doing
static allocation, so that in the future the static allocation gets
removed completely and dynamic allocation can start at base 0.

Christophe Leroy (8):
gpio: aggregator: Stop using ARCH_NR_GPIOS
gpio: davinci: Stop using ARCH_NR_GPIOS
gpiolib: Warn on drivers still using static gpiobase allocation
gpiolib: Get rid of ARCH_NR_GPIOS
Documentation: gpio: Remove text about ARCH_NR_GPIOS
x86: Remove CONFIG_ARCH_NR_GPIO
arm: Remove CONFIG_ARCH_NR_GPIO
arm64: Remove CONFIG_ARCH_NR_GPIO

Documentation/driver-api/gpio/legacy.rst | 5 ---
arch/arm/Kconfig | 21 ---------
arch/arm/include/asm/gpio.h | 1 -
arch/arm64/Kconfig | 12 ------
arch/x86/Kconfig | 5 ---
drivers/gpio/gpio-aggregator.c | 8 ++--
drivers/gpio/gpio-davinci.c | 3 --
drivers/gpio/gpio-sta2x11.c | 5 +--
drivers/gpio/gpiolib.c | 13 +++---
include/asm-generic/gpio.h | 55 +++++++++---------------
10 files changed, 36 insertions(+), 92 deletions(-)

--
2.37.1


2022-08-29 17:38:27

by Christophe Leroy

[permalink] [raw]
Subject: [PATCH v1 8/8] arm64: Remove CONFIG_ARCH_NR_GPIO

CONFIG_ARCH_NR_GPIO is not used anymore, remove it.

Signed-off-by: Christophe Leroy <[email protected]>
---
arch/arm64/Kconfig | 12 ------------
1 file changed, 12 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 571cc234d0b3..be64ae29cd02 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -2093,18 +2093,6 @@ config STACKPROTECTOR_PER_TASK
def_bool y
depends on STACKPROTECTOR && CC_HAVE_STACKPROTECTOR_SYSREG

-# The GPIO number here must be sorted by descending number. In case of
-# a multiplatform kernel, we just want the highest value required by the
-# selected platforms.
-config ARCH_NR_GPIO
- int
- default 2048 if ARCH_APPLE
- default 0
- help
- Maximum number of GPIOs in the system.
-
- If unsure, leave the default value.
-
endmenu # "Kernel Features"

menu "Boot options"
--
2.37.1

2022-08-29 17:45:05

by Christophe Leroy

[permalink] [raw]
Subject: [PATCH v1 6/8] x86: Remove CONFIG_ARCH_NR_GPIO

CONFIG_ARCH_NR_GPIO is not used anymore, remove it.

Signed-off-by: Christophe Leroy <[email protected]>
---
arch/x86/Kconfig | 5 -----
1 file changed, 5 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index f9920f1341c8..0385d5273e37 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -345,11 +345,6 @@ config ARCH_HAS_CPU_RELAX
config ARCH_HIBERNATION_POSSIBLE
def_bool y

-config ARCH_NR_GPIO
- int
- default 1024 if X86_64
- default 512
-
config ARCH_SUSPEND_POSSIBLE
def_bool y

--
2.37.1

2022-08-29 17:46:26

by Christophe Leroy

[permalink] [raw]
Subject: [PATCH v1 5/8] Documentation: gpio: Remove text about ARCH_NR_GPIOS

ARCH_NR_GPIOS have been removed, clean up the documentation.

After this patch, the only place when ARCH_NR_GPIOS remains is in
translations/zh_CN/gpio.txt and translations/zh_TW/gpio.txt.
I don't have the skills to update that, anyway those two files are
already out of sync as they are still mentionning ARCH_REQUIRE_GPIOLIB
which was removed by commit 65053e1a7743 ("gpio: delete
ARCH_[WANTS_OPTIONAL|REQUIRE]_GPIOLIB")

Signed-off-by: Christophe Leroy <[email protected]>
---
Documentation/driver-api/gpio/legacy.rst | 5 -----
1 file changed, 5 deletions(-)

diff --git a/Documentation/driver-api/gpio/legacy.rst b/Documentation/driver-api/gpio/legacy.rst
index 9b12eeb89170..e17910cc3271 100644
--- a/Documentation/driver-api/gpio/legacy.rst
+++ b/Documentation/driver-api/gpio/legacy.rst
@@ -558,11 +558,6 @@ 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
-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.
-
If neither of these options are selected, the platform does not support
GPIOs through GPIO-lib and the code cannot be enabled by the user.

--
2.37.1

2022-08-30 20:30:16

by Andy Shevchenko

[permalink] [raw]
Subject: Re: [PATCH v1 0/8] gpio: Get rid of ARCH_NR_GPIOS (v1)

On Mon, Aug 29, 2022 at 7:17 PM Christophe Leroy
<[email protected]> wrote:
>
> Since commit 14e85c0e69d5 ("gpio: remove gpio_descs global array")
> there is no limitation on the number of GPIOs that can be allocated
> in the system since the allocation is fully dynamic.
>
> ARCH_NR_GPIOS is today only used in order to provide downwards
> gpiobase allocation from that value, while static allocation is
> performed upwards from 0. However that has the disadvantage of
> limiting the number of GPIOs that can be registered in the system.
>
> To overcome this limitation without requiring each and every
> platform to provide its 'best-guess' maximum number, rework the
> allocation to allocate from 256 upwards, allowing approx 2 millions
> of GPIOs.
>
> In the meantime, add a warning for drivers how are still doing
> static allocation, so that in the future the static allocation gets
> removed completely and dynamic allocation can start at base 0.

For non-commented (by me or others) patches
Reviewed-by: Andy Shevchenko <andy.shevchenko!gmail.com>
For the patch 1 if you are going to address as suggested by the author
of the driver, you may also add my tag.

> Christophe Leroy (8):
> gpio: aggregator: Stop using ARCH_NR_GPIOS
> gpio: davinci: Stop using ARCH_NR_GPIOS
> gpiolib: Warn on drivers still using static gpiobase allocation
> gpiolib: Get rid of ARCH_NR_GPIOS
> Documentation: gpio: Remove text about ARCH_NR_GPIOS
> x86: Remove CONFIG_ARCH_NR_GPIO
> arm: Remove CONFIG_ARCH_NR_GPIO
> arm64: Remove CONFIG_ARCH_NR_GPIO
>
> Documentation/driver-api/gpio/legacy.rst | 5 ---
> arch/arm/Kconfig | 21 ---------
> arch/arm/include/asm/gpio.h | 1 -
> arch/arm64/Kconfig | 12 ------
> arch/x86/Kconfig | 5 ---
> drivers/gpio/gpio-aggregator.c | 8 ++--
> drivers/gpio/gpio-davinci.c | 3 --
> drivers/gpio/gpio-sta2x11.c | 5 +--
> drivers/gpio/gpiolib.c | 13 +++---
> include/asm-generic/gpio.h | 55 +++++++++---------------
> 10 files changed, 36 insertions(+), 92 deletions(-)
>
> --
> 2.37.1
>


--
With Best Regards,
Andy Shevchenko

2022-08-30 21:29:28

by Andy Shevchenko

[permalink] [raw]
Subject: Re: [PATCH v1 0/8] gpio: Get rid of ARCH_NR_GPIOS (v1)

On Tue, Aug 30, 2022 at 11:20 PM Andy Shevchenko
<[email protected]> wrote:
>
> On Mon, Aug 29, 2022 at 7:17 PM Christophe Leroy
> <[email protected]> wrote:
> >
> > Since commit 14e85c0e69d5 ("gpio: remove gpio_descs global array")
> > there is no limitation on the number of GPIOs that can be allocated
> > in the system since the allocation is fully dynamic.
> >
> > ARCH_NR_GPIOS is today only used in order to provide downwards
> > gpiobase allocation from that value, while static allocation is
> > performed upwards from 0. However that has the disadvantage of
> > limiting the number of GPIOs that can be registered in the system.
> >
> > To overcome this limitation without requiring each and every
> > platform to provide its 'best-guess' maximum number, rework the
> > allocation to allocate from 256 upwards, allowing approx 2 millions
> > of GPIOs.
> >
> > In the meantime, add a warning for drivers how are still doing
> > static allocation, so that in the future the static allocation gets
> > removed completely and dynamic allocation can start at base 0.
>
> For non-commented (by me or others) patches
> Reviewed-by: Andy Shevchenko <andy.shevchenko!gmail.com>

Should be
Reviewed-by: Andy Shevchenko <[email protected]>

> For the patch 1 if you are going to address as suggested by the author
> of the driver, you may also add my tag.



--
With Best Regards,
Andy Shevchenko