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: <dfd50de5149a38ad1bc5faf9bb26a8a04be7d314.camel@mediatek.com>
Date:   Sat, 18 Dec 2021 17:44:32 +0800
From:   Kewei Xu <kewei.xu@...iatek.com>
To:     Wolfram Sang <wsa@...-dreams.de>, <matthias.bgg@...il.com>,
        <robh+dt@...nel.org>, <linux-i2c@...r.kernel.org>,
        <devicetree@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>,
        <linux-mediatek@...ts.infradead.org>,
        <srv_heupstream@...iatek.com>, <leilk.liu@...iatek.com>,
        <qii.wang@...iatek.com>, <liguo.zhang@...iatek.com>,
        <caiyu.chen@...iatek.com>, <ot_daolong.zhu@...iatek.com>,
        <yuhan.wei@...iatek.com>
Subject: Re: [PATCH v7 6/7] i2c: mediatek: Isolate speed setting via dts for
 special devices

On Mon, 2021-11-29 at 13:49 +0100, Wolfram Sang wrote:
> > > stretching. But if the slave device stretch the SCL line for too
> > > long
> > > time, our design still cannot make tSU,STA/tHD,STA/tSU,STO meet
> > > spec.
> > 
> > Isn't the new algorithm broken if it cannot support clock
> > stretching?
> > What was the problem of the old algorithm not meeting the spec?
> > 
> > > However in the old (default) timing algorithm before the commit
> > > be5ce0e97cc7 ("i2c: mediatek: Add i2c ac-timing adjust support"),
> > > tSU,STA/tHD,STA/tSU,STO can meet spec. So we want to define a new
> > > setting "default-adjust-timing" for using the old (default)
> > > timing
> > > algorithm."
> > 
> > What I still do not get: the old algorithm was able to handle clock
> > stretching. Why can't you update the new one to handle clock
> > stretching
> > as well. I might be missing something, but what is it?
> 
> I am still interested. Especially in the last question. Is the last
> question clear to you? I can explain some more otherwise.
> 
Hi,Wolfram,

I'm very sorry that I didn't reply to your information in time due
to my many personal affairs.

The Old algorithm was designed to focus only on normal functions, and
need to add additional custom code to adjust ac-timing when the
communication timing did not meet the specifications. so when there is
no clock stretch, ac-timing does not meet the spec, but the function is
always normal.

The new algorithm(The commit patch: be5ce0e97cc7 ("i2c: mediatek: Add
i2c ac-timing adjust support") is based on the requirements of i2c spec
to calculate the hardware-related settings so that the function and ac-
timing are normal When there is no clock stretch or the clock stretch
time is short. When the stretching time is very long (>60us), i2c ac-
timing does not meet the specifications and causes function abnormal.

In order to make the i2c function normal, this patch was submitted,
that is, when the stretch is long, the old algorithm is used to ensure
the function is normal, and when the stretch is short, the new
algorithm is used to ensure that the ac-timing and function are normal.

We found that when the ac-timing calculation formula is updated, the
new algorithm can make i2c ac-timing meet the spec and function
normally. So we plan to replace this patch with a patch that updates
the calculation formula.

Thanks~
Kewei

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ