On Tue, Aug 9, 2022 at 12:41 PM 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 > > Signed-off-by: Christophe Leroy <christophe.leroy@xxxxxxxxxx> I see what you're trying to do and this might be a possible interim solution. I would like some comments sprinkled into the patched sites that this is supposed to go away. The GPIO descriptor refactoring which has been ongoing for a few years, see drivers/gpio/TODO (please read), has the end goal of making descriptor allocation fully dynamic. Once we free ourselves from the fixed GPIO numberspace, there is nothing preventing us from just kmalloc() ing a new descriptor whenever one is needed. Help with rooting out the remaining fixed GPIO number clients is much appreciated! The per-arch GPIO number only exist for one reason: embedded GPIOs (think SoC:s) that refer to fixed numbers in numberspace in the board support code. This makes it necessary to allocate descriptors up front in some compiled-in GPIO chips. Yours, Linus Walleij
