linux-kernel - Re: [PATCH v3 05/15] phy: rockchip-emmc: Increase lock time allowance

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: <CAD=FV=XTk_mY3oJaJX8sUnUzvNf3z8PtjanKJ1a8oWKDi7TwSQ@mail.gmail.com>
Date:	Mon, 20 Jun 2016 12:36:51 -0700
From:	Doug Anderson <dianders@...omium.org>
To:	Guenter Roeck <groeck@...gle.com>
Cc:	Ulf Hansson <ulf.hansson@...aro.org>,
	Heiko Stuebner <heiko@...ech.de>,
	Kishon Vijay Abraham I <kishon@...com>,
	Rob Herring <robh+dt@...nel.org>,
	Shawn Lin <shawn.lin@...k-chips.com>,
	Ziyuan Xu <xzy.xu@...k-chips.com>,
	Brian Norris <briannorris@...omium.org>,
	Adrian Hunter <adrian.hunter@...el.com>,
	"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Guenter Roeck <groeck@...omium.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v3 05/15] phy: rockchip-emmc: Increase lock time allowance

Hi,

On Mon, Jun 20, 2016 at 12:29 PM, Guenter Roeck <groeck@...gle.com> wrote:
> On Mon, Jun 20, 2016 at 10:56 AM, Douglas Anderson
> <dianders@...omium.org> wrote:
>> Previous PHY code waited a fixed amount of time for the DLL to lock at
>> power on time.  Unfortunately, the time for the DLL to lock is actually
>> a bit more dynamic and can be longer if the card clock is slower.
>>
>> Instead of waiting a fixed 30 us, let's now dynamically wait until the
>> lock bit gets set.  We'll wait up to 10 ms which should be OK even if
>> the card clock is at the super slow 100 kHz.
>>
>
> 10 ms active delay (no sleep) is actually quite long. Can this code sleep ?

It is expected that in nearly all cases it will be much shorter than
10ms.  The longest expected (at 400kHz) is 1.3 ms and we should only
be probing down to 300, 200, 100 kHz if we are having trouble
communicating.  When running at a normal speed (50 MHz, 100 MHz, etc)
it should be much smaller and closer to 10 us or less.  We could still
try to sleep in some of these cases, but IMHO the extra code
complexity for something like this that should happen very
infrequently (only at bootup or if we decide to re-tune) is probably
not worth it.  Also note that at boot eMMC is (probably) on the
critical path, so there may be some boot speed benefits to continuing
as quickly as possible.

-Doug