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@xxxxxx> wrote: > > It seems GPIOs on OMAP1 boards are somewhat broken after: > > > > commit 92bf78b33b0b463b00c6b0203b49aea845daecc8 > > Author: Andreas Kemnade <andreas@xxxxxxxxxxxx> > > 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.
