linux-kernel - Re: [PATCH v2 4/6] i2c: pasemi: Improve error recovery

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] [day] [month] [year] [list]

Message-Id: <c6590a37-97b0-4497-8cc1-c4572897f0dc@app.fastmail.com>
Date: Sun, 27 Apr 2025 13:29:17 +0200
From: "Sven Peter" <sven@...npeter.dev>
To: "Andi Shyti" <andi.shyti@...nel.org>
Cc: "Janne Grunau" <j@...nau.net>, "Alyssa Rosenzweig" <alyssa@...enzweig.io>,
 "Madhavan Srinivasan" <maddy@...ux.ibm.com>,
 "Michael Ellerman" <mpe@...erman.id.au>,
 "Nicholas Piggin" <npiggin@...il.com>,
 "Christophe Leroy" <christophe.leroy@...roup.eu>,
 "Naveen N Rao" <naveen@...nel.org>, "Neal Gompa" <neal@...pa.dev>,
 "Hector Martin" <marcan@...can.st>,
 linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>, asahi@...ts.linux.dev,
 linux-arm-kernel@...ts.infradead.org, linux-i2c@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 4/6] i2c: pasemi: Improve error recovery

Hi,

On Thu, Apr 17, 2025, at 15:07, Andi Shyti wrote:
> Hi Sven, Hector,
>
> ...
>
>> +/*
>> + * The hardware (supposedly) has a 25ms timeout for clock stretching, thus
>> + * use 100ms here which should be plenty.
>> + */
>> +#define TRANSFER_TIMEOUT_MS	100
>
> Please use the PASEMI prefix here. TRANSFER_TIMEOUT_MS it's not a
> naming belonging to this driver.
>
> 100ms looks a bit too much to me, but if you say it works, then
> it works.
>

The problem here is that we only have very outdated documentation for this
hardware and no real idea what changed since Apple bought PASemi and continued
using their i2c controller.
We know that 10ms (which used to be the original timeout iirc) is not nearly
enough and we also know that we need at least 25ms for clock strechting
(assuming nothing changed in the past 10+ years).
We just bumped it to 100ms to be safe after we very rarely got error
reports which we tracked down to timeouts and haven't gotten any reports
since.

I've addressed all your other comments for v3 which I'll send out in a few minutes.

Best,

Sven