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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAJX_Q+2F_b+1Q_qAi6ZLkT=EoW+JjoT-cyONSnoehd5mkfUdsg@mail.gmail.com>
Date:   Fri, 8 Apr 2022 08:19:28 +0100
From:   Lucas Tanure <tanure@...ux.com>
To:     Neil Armstrong <narmstrong@...libre.com>
Cc:     Kevin Hilman <khilman@...libre.com>,
        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

On Tue, Apr 5, 2022 at 4:11 PM Neil Armstrong <narmstrong@...libre.com> wrote:
>
> 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 ?

I only checked I2C interfaces i2c3 and i2c_ao.
I will submit a new patch chain with more results.

>
> Neil
>
> >
> > Thanks
> > Lucas
> >
> >
> >
>