Re: [BISECTED REGRESSION] OMAP1 GPIO breakage

[Andreas Kemnade <andreas@kemnade.info>]

On Wed, 26 Apr 2023 13:52:51 +0300
andy.shevchenko@gmail.com 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@atomide.com> wrote:  
> > > * Andreas Kemnade <andreas@kemnade.info> [230425 19:58]:  
> > > > On Tue, 25 Apr 2023 22:36:37 +0300
> > > > Aaro Koskinen <aaro.koskinen@iki.fi> wrote:  
> > > > > On Tue, Apr 25, 2023 at 09:20:40PM +0200, Andreas Kemnade wrote:    
> > > > > > Aaro Koskinen <aaro.koskinen@iki.fi> 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