From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Bartosz Golaszewski <brgl@bgdev.pl>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Keerthy <j-keerthy@ti.com>, Russell King <linux@armlinux.org.uk>,
Arnd Bergmann <arnd@arndb.de>, Jonathan Corbet <corbet@lwn.net>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Davide Ciminaghi <ciminaghi@gnudd.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
linux-arm Mailing List <linux-arm-kernel@lists.infradead.org>,
Linux-Arch <linux-arch@vger.kernel.org>,
Linux Documentation List <linux-doc@vger.kernel.org>,
"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
<x86@kernel.org>
Subject: Re: [PATCH v2 5/9] gpiolib: Get rid of ARCH_NR_GPIOS
Date: Fri, 2 Sep 2022 15:22:20 +0000 [thread overview]
Message-ID: <63b3c26a-be33-6ef3-7feb-ff7997fbc752@csgroup.eu> (raw)
In-Reply-To: <CAHp75Ve6zMC9s=TZT_pWoyxnKtXE0xipFCv_RDY4r4amnVbVxQ@mail.gmail.com>
Le 02/09/2022 à 16:58, Andy Shevchenko a écrit :
> On Fri, Sep 2, 2022 at 4:57 PM Christophe Leroy
> <christophe.leroy@csgroup.eu> 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 upwards, allowing approx 2 millions of
>> GPIOs.
>>
>> In order to still allow static allocation for legacy drivers, define
>> GPIO_DYNAMIC_BASE with the value 512 as the start for dynamic
>> allocation. The 512 value is chosen because it is the end of
>> the current default range so all current static allocations are
>> expected to be below that value. Of course that's just a rough
>> estimate based on the default value, but assuming static
>> allocations come first, even if there are more static allocations
>> it should fit under the 512 value.
>>
>> In the future, it is expected that all static allocations go away
>> and then dynamic allocation will be patched to start at 0.
>
> Eventually we have to get rid of gpio_is_valid() completely...
> But this is another story.
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Yes that could be done as a follow-up.
There are about 300 call sites.
Should simply replace gpio_is_valid(gpio) by gpio >= 0. And then verify
that the check is really required. But needs to check signness of gpio
at every place.
First look seems already promissing:
int gpio_request_one(unsigned gpio, unsigned long flags, const char *label)
{
struct gpio_desc *desc;
int err;
desc = gpio_to_desc(gpio);
/* Compatibility: assume unavailable "valid" GPIOs will appear later */
if (!desc && gpio_is_valid(gpio))
return -EPROBE_DEFER;
next prev parent reply other threads:[~2022-09-02 15:36 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-02 12:42 [PATCH v2 0/9] gpio: Get rid of ARCH_NR_GPIOS (v2) Christophe Leroy
2022-09-02 12:42 ` [PATCH v2 1/9] gpio: Remove sta2x11 GPIO driver Christophe Leroy
2022-09-02 12:42 ` [PATCH v2 2/9] gpio: aggregator: Stop using ARCH_NR_GPIOS Christophe Leroy
2022-09-02 12:42 ` [PATCH v2 3/9] gpio: davinci: " Christophe Leroy
2022-09-02 12:42 ` [PATCH v2 4/9] gpiolib: Warn on drivers still using static gpiobase allocation Christophe Leroy
2022-09-02 12:42 ` [PATCH v2 5/9] gpiolib: Get rid of ARCH_NR_GPIOS Christophe Leroy
2022-09-02 14:58 ` Andy Shevchenko
2022-09-02 15:22 ` Christophe Leroy [this message]
2022-09-02 12:42 ` [PATCH v2 6/9] Documentation: gpio: Remove text about ARCH_NR_GPIOS Christophe Leroy
2022-09-02 12:42 ` [PATCH v2 7/9] x86: Remove CONFIG_ARCH_NR_GPIO Christophe Leroy
2022-10-17 9:16 ` Thomas Gleixner
2022-09-02 12:42 ` [PATCH v2 8/9] arm: " Christophe Leroy
2022-09-02 12:42 ` [PATCH v2 9/9] arm64: " Christophe Leroy
2022-09-07 9:58 ` [PATCH v2 0/9] gpio: Get rid of ARCH_NR_GPIOS (v2) Bartosz Golaszewski
2022-09-07 10:14 ` Arnd Bergmann
2022-09-14 12:38 ` Linus Walleij
2022-09-14 13:02 ` Andy Shevchenko
2022-09-14 13:03 ` Arnd Bergmann
2022-10-14 14:13 ` Christophe Leroy
2022-10-14 14:22 ` Bartosz Golaszewski
2022-10-17 9:04 ` Bartosz Golaszewski
2022-10-17 9:06 ` Linus Walleij
2022-10-17 12:11 ` Andy Shevchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=63b3c26a-be33-6ef3-7feb-ff7997fbc752@csgroup.eu \
--to=christophe.leroy@csgroup.eu \
--cc=andy.shevchenko@gmail.com \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=brgl@bgdev.pl \
--cc=catalin.marinas@arm.com \
--cc=ciminaghi@gnudd.com \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=geert+renesas@glider.be \
--cc=hpa@zytor.com \
--cc=j-keerthy@ti.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®