Re: [BISECTED REGRESSION] OMAP1 GPIO breakage

[andy.shevchenko@xxxxxxxxx]

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:    

...

> > > > > > Which commit introduced that regression? Also, the changelog mentions
> > > > > > it happens only with "unusual" probe order. Now, all the ordinary cases
> > > > > > for OMAP1 are broken.
> > > > > >     
> > > > > did not bisect that to an exact commit.
> > > > > Unusual probe order: on the device where I tested it,
> > > > > I did not see a completely successful probe.    
> > > > 
> > > > If you cannot point out a working past commit, there was no regression. If
> > > > you fix something that hasn't worked before or has been long time broken,
> > > > it must not cause breakage to other current users.
> > > >   
> > > Well, I did not take the time for a bisect. As we need a less aggressive
> > > fix, it seems to be worth doing it. 
> > >   
> > > > > > And it's not just that tps65010 thing. E.g. 770 fails to boot as well
> > > > > > and it doesn't use it; and reverting 92bf78b33b0b fixes that one as
> > > > > > well. AFAIK it's because all the gpio_request()s in OMAP1 board files
> > > > > > stopped now working.
> > > > > >     
> > > > > so we break every non-devicetree user of omap-gpio?     
> > > > 
> > > > It seems so.
> > > >   
> > > or maybe an if (not_using_devicetree())  
> > 
> > Not sure what the best way to fix this might be, adding Linus W to Cc too.
> > Maybe using gpio line names in the legacy platform data instead of numbers?
> > 
> > Seems that we should just revert this patch for now and try again after
> > the issues have been fixed.
> >
> 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?


-- 
With Best Regards,
Andy Shevchenko