Le 26/08/2022 à 23:54, Linus Walleij a écrit : > On Fri, Aug 26, 2022 at 5:08 PM Christophe Leroy > <christophe.leroy@xxxxxxxxxx> wrote: >> Le 26/08/2022 à 15:49, Linus Walleij a écrit : >>> On Thu, Aug 25, 2022 at 4:00 PM Christophe Leroy >>> <christophe.leroy@xxxxxxxxxx> wrote: >>> >>>>> Christophe? Will you take a stab at it? >>>> >>>> Which patch should I write ? >>> >>> One that removes CONFIG_ARCH_HAS_NR_GPIO entirely, then >>> allocate bases for new GPIO chips from 0 and upward instead. >>> And then see what happens. >>> >> >> Ok, I can give it a try. > > Nice! > >> But what do I do with: >> >> drivers/gpio/gpio-aggregator.c: bitmap = bitmap_alloc(ARCH_NR_GPIOS, >> GFP_KERNEL); > > That's just used locally in that driver to loop over the arguments to the > aggregator (from the file in sysfs). I would set some arbitrary root > like > #define AGGREGATOR_MAX_GPIOS 512 > and just search/replace with that. > And what about gsta_gpio_setup() that requests base 0 with the following comment: /* * ARCH_NR_GPIOS is currently 256 and dynamic allocation starts * from the end. However, for compatibility, we need the first * ConneXt device to start from gpio 0: it's the main chipset * on most boards so documents and drivers assume gpio0..gpio127 */ And I guess there might be other drivers like that (I found that one because of its comment mentionning ARCH_NR_GPIOS. Another solution could be to leave first GPIOs for static allocation, and allocate dynamic ones from 256 or from 512 ? Maybe in two steps: - First step: Allocate dynamic from 256 upwards and add a pr_warn() for all static allocations. - Second step later: Allocate dynamic from 0 and forbid static allocation. Any opinion ? Christophe
