Re: [BISECTED REGRESSION] OMAP1 GPIO breakage

From: Andreas Kemnade
Date: Wed Apr 26 2023 - 14:29:29 EST


On Wed, 26 Apr 2023 13:52:51 +0300
andy.shevchenko@xxxxxxxxx wrote:

> Wed, Apr 26, 2023 at 09:39:20AM +0200, Andreas Kemnade kirjoitti:
> > On Wed, 26 Apr 2023 10:19:10 +0300
> > Tony Lindgren <tony@xxxxxxxxxxx> wrote:
> > > * Andreas Kemnade <andreas@xxxxxxxxxxxx> [230425 19:58]:
> > > > On Tue, 25 Apr 2023 22:36:37 +0300
> > > > Aaro Koskinen <aaro.koskinen@xxxxxx> wrote:
> > > > > On Tue, Apr 25, 2023 at 09:20:40PM +0200, Andreas Kemnade wrote:
> > > > > > Aaro Koskinen <aaro.koskinen@xxxxxx> wrote:
>
> ...
[...]
> > I think the reason for the patch (besides of cleaning up warnings) is that
> > dynamic allocation seems to start at 512, static at zero.
> > If both are there, like registering twl_gpio between omap gpiochip 4 and 5,
> > dynamic allocation seems just to start after the last static number,
> > calling for trouble.
> >
> > If dynamic alloc would just start at 512 in that case too, no problem would appear.
> > As said I have not bisected it to an exact commit yet.
> > So if we need to move backward, we should IMHO first fix that allocation thing.
>
> I agree.
>
> As PoC can the reported add the following lines
>
> if (gdev->base < GPIO_DYNAMIC_BASE)
> continue;
>
> after https://elixir.bootlin.com/linux/latest/source/drivers/gpio/gpiolib.c#L190
> and test your idea?
>
>
yes,
looking at git blame
7b61212f2a07a ("gpiolib: Get rid of ARCH_NR_GPIOS")

would probably have been the correct Fixes-tag for for that patch (and
will be for the new approach to fix it) and its intention was exactly
what we are talking about.

I will test.

Regards,
Andreas