linux-kernel - [PATCH v1 0/8] gpio: Get rid of ARCH_NR

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <cover.1661789204.git.christophe.leroy@csgroup.eu>
Date:   Mon, 29 Aug 2022 18:15:02 +0200
From:   Christophe Leroy <christophe.leroy@...roup.eu>
To:     Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <brgl@...ev.pl>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Keerthy <j-keerthy@...com>, Russell King <linux@...linux.org.uk>,
        Arnd Bergmann <arnd@...db.de>,
        Jonathan Corbet <corbet@....net>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>
Cc:     Christophe Leroy <christophe.leroy@...roup.eu>,
        linux-kernel@...r.kernel.org, linux-gpio@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-arch@...r.kernel.org,
        linux-doc@...r.kernel.org, x86@...nel.org
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