On August 12, 2022 2:58:36 PM PDT, Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote: >On Thu, Aug 11, 2022 at 11:12 PM H. Peter Anvin <hpa@xxxxxxxxx> wrote: >> >> On August 9, 2022 3:40:38 AM PDT, Christophe Leroy <christophe.leroy@xxxxxxxxxx> wrote: >> >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 > >... > >> This seems very odd to me. GPIOs can be, and often are, attached to peripheral buses which means that the *same system* can have anything from none to thousands of gpios .. > >Basically this setting should give us a *minimum* GPIO lines that are >present on the system. And that is perfectly SoC dependent. The real >issue is that the GPIO framework has these global arrays that (still?) >can't be initialized from the heap due to too early initialization (is >it the true reason?). > Ok that makes more sense... but in that case, it would also be good to reclaim excess storage that turns out to not be needed. I am a bit skeptical, though – we get basic memory allocation very early.