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]

Message-ID: <20230425212040.5a4d5b09@aktux>
Date:   Tue, 25 Apr 2023 21:20:40 +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 21:38:57 +0300
Aaro Koskinen <aaro.koskinen@....fi> wrote:

> Hi,
> 
> On Tue, Apr 25, 2023 at 08:11:17PM +0200, Andreas Kemnade wrote:
> > On Tue, 25 Apr 2023 20:32:41 +0300
> > Aaro Koskinen <aaro.koskinen@....fi> wrote:  
> > > It seems GPIOs on OMAP1 boards are somewhat broken after:
> > > 
> > > commit 92bf78b33b0b463b00c6b0203b49aea845daecc8
> > > Author: Andreas Kemnade <andreas@...nade.info>
> > > Date:   Fri Jan 13 21:59:22 2023 +0100
> > > 
> > >     gpio: omap: use dynamic allocation of base
> > > 
> > > E.g. on OSK1 the ethernet IRQ cannot (omap_gpio.0) no longer be requested:
> > > 
> > > [    0.277252] Error requesting gpio 0 for smc91x irq
> > > 
> > > Also the tps65010 (still using static allocation) will now conflict:
> > > 
> > > [    0.400726] gpio gpiochip5: Static allocation of GPIO base is deprecated, use dynamic allocation.
> > > [    0.400848] gpio gpiochip5: (tps65010): GPIO integer space overlap, cannot add chip
> > > [    0.400970] gpiochip_add_data_with_key: GPIOs 208..214 (tps65010) failed to register, -16
> > > [    0.401092] tps65010 i2c-tps65010: can't add gpiochip, err -16
> > > 
> > > I think this change should be reverted until the board files and other
> > > gpiochips are fixed accordingly.
> > >   
> > well, then just fix that tps65010 thing. 
> > 
> > that change is itself a regression fix for exactly the same kind of error.  
> 
> 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.

> 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? 

Regards,
Andreas