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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Wed, 26 Apr 2023 10:19:10 +0300
From:   Tony Lindgren <tony@...mide.com>
To:     Andreas Kemnade <andreas@...nade.info>
Cc:     Aaro Koskinen <aaro.koskinen@....fi>, linux-omap@...r.kernel.org,
        linux-gpio@...r.kernel.org,
        Bartosz Golaszewski <bartosz.golaszewski@...aro.org>,
        linux-kernel@...r.kernel.org,
        Linus Walleij <linus.walleij@...aro.org>
Subject: Re: [BISECTED REGRESSION] OMAP1 GPIO breakage

Hi,

* Andreas Kemnade <andreas@...nade.info> [230425 19:58]:
> 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())

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.

Regards,

Tony