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]

Date:	Mon, 20 Jun 2016 12:38:27 -0700
From:	Guenter Roeck <groeck@...gle.com>
To:	Doug Anderson <dianders@...omium.org>
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

On Mon, Jun 20, 2016 at 12:36 PM, Doug Anderson <dianders@...omium.org> wrote:
> 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.
>

Makes sense.

Thanks,
Guenter