linux-kernel - Re: [PATCH v9 2/2] i2c: riic: Recover from arbitration loss

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: <CA+V-a8t8AApJTgF8Zc3w+JjAu6yPvzUEgTo0g+1H+6GhvJUdbA@mail.gmail.com>
Date: Thu, 1 May 2025 10:02:18 +0100
From: "Lad, Prabhakar" <prabhakar.csengg@...il.com>
To: Wolfram Sang <wsa+renesas@...g-engineering.com>, 
	"Lad, Prabhakar" <prabhakar.csengg@...il.com>, Chris Brandt <chris.brandt@...esas.com>, 
	Andi Shyti <andi.shyti@...nel.org>, Geert Uytterhoeven <geert+renesas@...der.be>, 
	Andy Shevchenko <andy@...nel.org>, linux-renesas-soc@...r.kernel.org, 
	linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Biju Das <biju.das.jz@...renesas.com>, 
	Fabrizio Castro <fabrizio.castro.jz@...esas.com>, 
	Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
Subject: Re: [PATCH v9 2/2] i2c: riic: Recover from arbitration loss

Hi Wolfram,

On Thu, May 1, 2025 at 8:58 AM Wolfram Sang
<wsa+renesas@...g-engineering.com> wrote:
>
>
> > Do you mean that upon detecting an arbitration loss, we simply clear
> > the arbitration bit and retry?
>
> Yes, after the bus is considered free again.
>
I'll give that a try but in my case the SDA line has gone low.

> > However, when observing the SDA line after recovery, it goes LOW again
> > during the transfer. I've attached a screenshot of this case: we
> > recovered from a bus hang, the I2C recovery algorithm brought the bus
> > to a STOP state, and then a START condition was issued. But after
> > initiating the transfer, we can see the SDA line being held LOW again.
>
> That looks weird. Why are there two SDA transitions around 30us? Why is
> SDA changed while SCL is high around 45us? Then, this small SCL spike
> around 55us... What device is this?
>
>From 10µs to 50µs, the clock pulses are part of the recovery sequence.
The SDA line is likely being toggled by the slave around 30µs, after
two clock pulses. At 45µs, we are still within the recovery algorithm
-- SCL is set to 1, followed by SDA. The recovery algorithm then
checks if SCL is high and whether the bus is free (i.e., SDA is also
high). At that point, i2c_generic_scl_recovery() returns, assuming the
bus has been successfully recovered.
Around 55µs, the transfer function starts attempting to send data
hence the clock pulse.

The slave device is versa clock geberator 5P35023 (exact part number
on SMARC RZ/G2L 5P35023B-629NLGI)
https://www.renesas.com/en/products/clocks-timing/clock-generation/programmable-clocks/5p35023-versaclock-3s-programmable-clock-generator?srsltid=AfmBOoqlLSt_ul3hLh7NHYlCShXsnH-QZf90uSdoxZXI_Pre5Qg7soD6#overview

Cheers,
Prabhaka