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:   Tue, 25 Apr 2023 21:38:57 +0300
From:   Aaro Koskinen <aaro.koskinen@....fi>
To:     Andreas Kemnade <andreas@...nade.info>
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

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.

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.

A.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ