On Wed, Apr 26, 2023 at 11:33 PM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
>
> Aaro reports problems on the OSK1 board after we altered
> the dynamic base for GPIO allocations.
>
> It appears this happens because the OMAP driver now
> allocates GPIO numbers dynamically, so all that is
> references by number is a bit up in the air.
>
> Let's bite the bullet and try to just move the gpio_chip
> in the tps65010 MFD driver over to using dynamic allocations.
> Alter everything in the OSK1 board file to use a GPIO
> descriptor table and lookups.
>
> Utilize the NULL device to define some board-specific
> GPIO lookups and use these to immediately look up the
> same GPIOs, convert to IRQ numbers and pass as resources
> to the devices. This is ugly but should work.
>
> The .setup() callback for tps65010 was used for some GPIO
> hogging, but since the OSK1 is the only user in the entire
> kernel we can alter the signatures to something that
> is helpful and make a clean transition.
>
> Fixes: 7b61212f2a07 ("gpiolib: Get rid of ARCH_NR_GPIOS")
> Cc: Christophe Leroy <christophe.leroy@xxxxxxxxxx>
> Cc: andy.shevchenko@xxxxxxxxx
> Cc: Andreas Kemnade <andreas@xxxxxxxxxxxx>
> Cc: Lee Jones <lee@xxxxxxxxxx>
> Reported-by: Aaro Koskinen <aaro.koskinen@xxxxxx>
> Signed-off-by: Linus Walleij <linus.walleij@xxxxxxxxxx>
> ---
> This is a hopeless patch, if the subsystem maintainers are
> OK with it, I guess it should be merged into the SoC
> tree.
>
> If this approach works we can use the same approach for
> any other potentially broken OMAP1 platform.
Independently of the (potential) changes in GPIO library on how to
allocate the base, this should go upstream in my opinion as it's the
right direction to go.
--
With Best Regards,
Andy Shevchenko
