linux-kernel - Re: [PATCH] i2c: rk3x: fix bug that cause measured high

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]

Date:	Tue, 2 Dec 2014 15:02:37 -0800
From:	Doug Anderson <dianders@...omium.org>
To:	Addy Ke <addy.ke@...k-chips.com>
Cc:	Wolfram Sang <wsa@...-dreams.de>,
	Max Schwarz <max.schwarz@...ine.de>,
	Heiko Stübner <heiko@...ech.de>,
	Olof Johansson <olof@...om.net>,
	"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
	Eddie Cai <cf@...k-chips.com>, Jianqun Xu <xjq@...k-chips.com>,
	Tao Huang <huangtao@...k-chips.com>,
	Chris <zyw@...k-chips.com>,
	姚智情 <yzq@...k-chips.com>,
	han jiang <hj@...k-chips.com>,
	Kever Yang <kever.yang@...k-chips.com>,
	Lin Huang <hl@...k-chips.com>,
	晓腾王 <caesar.wang@...k-chips.com>,
	Shunqian Zheng <zhengsq@...k-chips.com>
Subject: Re: [PATCH] i2c: rk3x: fix bug that cause measured high_ns doesn't
 meet I2C spec

Addy,

On Thu, Nov 6, 2014 at 12:11 AM, Addy Ke <addy.ke@...k-chips.com> wrote:
> high_ns calculated from the low division of CLKDIV register is the sum of
> actual measured high_ns and rise_ns. The rise time which related to
> external pull-up resistor can be up to the maximum rise time in I2C spec.
>
> In my test, if external pull-up resistor is 4.7K, rise_ns is about 700ns.
> So the actual measured high_ns is about 3900ns, which is less than 4000ns
> (the minimum high_ns in I2C spec).

It's a little unfortunate to have to make the assumption that the rise
time for a board is going to be the maximum the spec allows.  I think
this is something that's better to let a board specify in the device
tree.  Allowing us to specify it also gives us a little extra slop and
makes it easier to specify a "fall time" without affecting the
resulting frequency.  Right now your code assumes that the fall time
is 0.

I've prototyped what things could look like if the rise and fall times
were specified in the device tree.  You can see my patch (atop yours)
at:

https://chromium-review.googlesource.com/#/c/232774/

...perhaps you could squash that into your patch and post up v2?

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/