linux-kernel - Re: [BISECTED REGRESSION] OMAP1 GPIO breakage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 25 Apr 2023 21:58:48 +0200
From:   Andreas Kemnade <andreas@...nade.info>
To:     Aaro Koskinen <aaro.koskinen@....fi>
Cc:     linux-omap@...r.kernel.org, linux-gpio@...r.kernel.org,
        Bartosz Golaszewski <bartosz.golaszewski@...aro.org>,
        Tony Lindgren <tony@...mide.com>, linux-kernel@...r.kernel.org
Subject: Re: [BISECTED REGRESSION] OMAP1 GPIO breakage

On Tue, 25 Apr 2023 22:36:37 +0300
Aaro Koskinen <aaro.koskinen@....fi> wrote:

> On Tue, Apr 25, 2023 at 09:20:40PM +0200, Andreas Kemnade wrote:
> > Aaro Koskinen <aaro.koskinen@....fi> 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())

Regards,
Andreas