Re: [BISECTED REGRESSION] OMAP1 GPIO breakage

[Andreas Kemnade <andreas@xxxxxxxxxxxx>]

Hi,

On Wed, 26 Apr 2023 10:19:10 +0300
Tony Lindgren <tony@xxxxxxxxxxx> wrote:

> Hi,
> 
> * 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.

Regards,
Andreas