linux-kernel - Re: [PATCH 0/3] Ensure Low period of SCL is correct

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

Message-ID: <a27da359-3922-e4ee-16d2-b4cb6fc06ca8@baylibre.com>
Date:   Tue, 5 Apr 2022 17:11:18 +0200
From:   Neil Armstrong <narmstrong@...libre.com>
To:     tanure@...ux.com, Kevin Hilman <khilman@...libre.com>
Cc:     Jerome Brunet <jbrunet@...libre.com>,
        Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
        linux-i2c@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-amlogic@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] Ensure Low period of SCL is correct

Hi,

On 28/03/2022 23:51, Lucas Tanure wrote:
> 
> 
> On Mon, 28 Mar 2022, 21:37 Kevin Hilman, <khilman@...libre.com <mailto:khilman@...libre.com>> wrote:
> 
>     Hi Lucas,
> 
>     Lucas Tanure <tanure@...ux.com <mailto:tanure@...ux.com>> writes:
> 
>      > The default duty cycle of 33% is less than the required
>      > by the I2C specs for the LOW period of the SCL clock.
>      >
>      > So, for 100Khz or less, use 50%H/50%L duty cycle, and
>      > for the clock above 100Khz, use 40%H/60%L duty cycle.
>      > That ensures the low period of SCL is always more than
>      > the minimum required by the specs at any given frequency.
> 
>     Thanks for the fixes!
> 
>     This is going to affect all SoCs, so ould you please summarize how your
>     changes were tested, and on which SoCs & boards?
> 
>     Thanks,
> 
>     Kevin
> 
> 
> Hi,
> 
> I only tested against vim3 board, measured the bus with an saleae logic pro 16.
> The measurements were with 100k, 400k and a few in between frequencies.
> 
> Is that enough?

I did a few measures on the Libre Computer Le Potato S905X board:

i2c_AO:

Before the patchset, I got:
- 100KHz: 1.66uS HIGH, 6.75uS LOW, 20%/80%, Freq 118KHz /!\
- 400KHz: Unable to decode, clock line is invalid, Data line is also invalid

With the patchset
- 100KHz: 4.25uS HIGH, 6.58uS LOW, 40%/60%, Freq 92KHz
- 400KHz: 0.33uS HIGH, 3.00uS LOW, 10%/90%, Freq 300KHz

i2c_B:

Before the patchset, I got:
- 100KHz: 2.25uS HIGH, 5.41uS LOW, 29%/71%, Freq 130KHz /!\
- 400KHz: 0.42uS HIGH, 1.66uS LOW, 20%/80%, Freq 480KHz /!\

With the patchset
- 100KHz: 4.75uS HIGH, 5.42uS LOW, 46%/54%, Freq 98KHz
- 400KHz: 0.66uS HIGH, 2.00uS LOW, 24%/75%, Freq 375KHz


So this fixes the frequency, before they were invalid.
And it fixes 400KHz on i2c_AO...

I do not understand why behavior is different between i2c_AO & i2c_B, they
are feed with the same clock so it should be the same.

Did you check on both i2c interfaces ? can you share your results ?

Neil

> 
> Thanks
> Lucas
> 
> 
>