linux-kernel - Re: [PATCH] i2c: omap: fix IRQ storms

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: <c3bcusjbn23z5yd2a3xtm7swnfizkl7rb6ufhicdhn52epnjvb@5uqm3g6jcony>
Date: Wed, 19 Feb 2025 20:22:13 +0100
From: Andi Shyti <andi.shyti@...nel.org>
To: Andreas Kemnade <andreas@...nade.info>
Cc: vigneshr@...com, aaro.koskinen@....fi, khilman@...libre.com, 
	rogerq@...nel.org, tony@...mide.com, jmkrzyszt@...il.com, reidt@...com, 
	wsa@...nel.org, linux-omap@...r.kernel.org, linux-i2c@...r.kernel.org, 
	linux-kernel@...r.kernel.org, stable@...nel.org
Subject: Re: [PATCH] i2c: omap: fix IRQ storms

Hi,

On Fri, Feb 07, 2025 at 07:54:35PM +0100, Andreas Kemnade wrote:
> On the GTA04A5 writing a reset command to the gyroscope causes IRQ
> storms because NACK IRQs are enabled and therefore triggered but not
> acked.
> 
> Sending a reset command to the gyroscope by
> i2cset 1 0x69 0x14 0xb6
> with an additional debug print in the ISR (not the thread) itself
> causes
> 
> [ 363.353515] i2c i2c-1: ioctl, cmd=0x720, arg=0xbe801b00
> [ 363.359039] omap_i2c 48072000.i2c: addr: 0x0069, len: 2, flags: 0x0, stop: 1
> [ 363.366180] omap_i2c 48072000.i2c: IRQ LL (ISR = 0x1110)
> [ 363.371673] omap_i2c 48072000.i2c: IRQ (ISR = 0x0010)
> [ 363.376892] omap_i2c 48072000.i2c: IRQ LL (ISR = 0x0102)
> [ 363.382263] omap_i2c 48072000.i2c: IRQ LL (ISR = 0x0102)
> [ 363.387664] omap_i2c 48072000.i2c: IRQ LL (ISR = 0x0102)
> repeating till infinity
> [...]
> (0x2 = NACK, 0x100 = Bus free, which is not enabled)
> Apparently no other IRQ bit gets set, so this stalls.
> 
> Do not ignore enabled interrupts and make sure they are acked.
> If the NACK IRQ is not needed, it should simply not enabled, but
> according to the above log, caring about it is necessary unless
> the Bus free IRQ is enabled and handled. The assumption that is
> will always come with a ARDY IRQ, which was the idea behind
> ignoring it, proves wrong.
> It is true for simple reads from an unused address.
> 
> So revert
> commit c770657bd261 ("i2c: omap: Fix standard mode false ACK readings").
> 
> The offending commit was used to reduce the false detections in
> i2cdetect. i2cdetect warns for confusing the I2C bus, so having some
> rare false detections (I have never seen such on my systems) is the
> lesser devil than having basically the system hanging completely.
> 
> No more details came to light in the corresponding email thread since
> several months:
> https://lore.kernel.org/linux-omap/20230426194956.689756-1-reidt@ti.com/
> so no better fix to solve both problems can be developed right now.

I need someone from TI or someone who can test to ack here.

Can someone help?

Thanks,
Andi