linux-kernel - Re: [PATCH 3/5] mmc: core: changes frequency to hs_max

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: <CAPDyKFrNp=Y3BhVE_kxtggv7Qc6m=2kef2U8Dn2Bb3ANHPYV-Q@mail.gmail.com>
Date:   Thu, 22 Sep 2016 12:21:17 +0200
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Shawn Lin <shawn.lin@...k-chips.com>
Cc:     Adrian Hunter <adrian.hunter@...el.com>,
        Jaehoon Chung <jh80.chung@...sung.com>,
        linux-mmc <linux-mmc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>
Subject: Re: [PATCH 3/5] mmc: core: changes frequency to hs_max_dtr when
 selecting hs400es

On 22 September 2016 at 12:06, Shawn Lin <shawn.lin@...k-chips.com> wrote:
> Hi ulf,
>
> 在 2016/9/22 17:38, Ulf Hansson 写道:
>>
>> On 21 September 2016 at 03:43, Shawn Lin <shawn.lin@...k-chips.com> wrote:
>>>
>>> Per JESD84-B51 P69, Host need to change frequency to <=52MHz after
>>> setting HS_TIMING to 0x1, and host may changes frequency to <= 200MHz
>>> after setting HS_TIMING to 0x3. It seems there is no difference if
>>> we don't change frequency to <= 52MHz as f_init is already less than
>>> 52MHz. But actually it does make difference. When doing compatibility
>>> test we see failures for some eMMC devices without changing the
>>> frequency to hs_max_dtr. And let's read the spec again, we could see
>>> that "Host may changes frequency to 200MHz" implies that it's not
>>> mandatory. But the "Host need to change frequency to <= 52MHz" implies
>>> that we should do this.
>>
>>
>> I don't get this. Are you saying that f_init > 52 MHz? That should not
>> be impossible, right!?
>
>
> nope, I was saying that the spec implies we to set clock after
> setting HS_TIMING to 0x1 when doing hs400es selection.
>
> I thought there is no difference because the spec says "Host need to
> change frequency to <= 52MHz", and the f_init(<=400k) is <= 52MHz,
> right? So I didn't set clock to hs_max_dtr. But I think I misunderstood
> the spec, so this patch will fix this.

Okay, I see what you mean now!

In other words:
The card expects the clock rate to increase from the current used
f_init (which is <= 400KHz), but still being <= 52MHz, when you have
set HS_TIMING to 0x1.

Okay, we can do that change! Could you try to improve the change log a
little bit or you want me to help?

Kind regards
Uffe