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 for Android: free password hash cracker in your pocket

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

Message-Id: <115FEE67-85FB-4D79-B87E-8DEF08019958@goldelico.com>
Date: Thu, 20 Feb 2025 09:43:30 +0100
From: "H. Nikolaus Schaller" <hns@...delico.com>
To: Andi Shyti <andi.shyti@...nel.org>
Cc: Andreas Kemnade <andreas@...nade.info>,
 "Raghavendra, Vignesh" <vigneshr@...com>,
 Aaro Koskinen <aaro.koskinen@....fi>,
 Kevin Hilman <khilman@...libre.com>,
 Roger Quadros <rogerq@...nel.org>,
 Tony Lindgren <tony@...mide.com>,
 Janusz Krzysztofik <jmkrzyszt@...il.com>,
 Reid Tonking <reidt@...com>,
 wsa@...nel.org,
 Linux-OMAP <linux-omap@...r.kernel.org>,
 linux-i2c@...r.kernel.org,
 Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
 stable@...nel.org
Subject: Re: [PATCH] i2c: omap: fix IRQ storms

Hi,

> Am 19.02.2025 um 20:22 schrieb Andi Shyti <andi.shyti@...nel.org>:
> 
> 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?

Well, I think since this is simply a full revert of

commit c770657bd261 ("i2c: omap: Fix standard mode false ACK readings")

to the status before. Therefore the status after revert was tested for many years
until c770657bd261 arrived to try to solve one issue but it apparently introduced
another one which is more severe and difficult to work around.

For real world tests please see also:

https://lore.kernel.org/linux-omap/664241E0-8D6B-4783-997B-2D8510ADAEA3@goldelico.com/
https://lore.kernel.org/linux-omap/ad0fe7ca-fb6c-4c19-b4b3-0f29ddaa92c3@jm0.eu/

BR and thanks,
Nikolaus