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: <62a8d622-39d2-db7d-042d-5425a3efba58@rock-chips.com>
Date:   Thu, 22 Sep 2016 18:06:52 +0800
From:   Shawn Lin <shawn.lin@...k-chips.com>
To:     Ulf Hansson <ulf.hansson@...aro.org>
Cc:     shawn.lin@...k-chips.com, 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

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.


>
> So either the core has changed the clock rate by mistake at some other
> execution path, or the host driver didn't set the correct clock rate
> the first time when invoked via mmc_power_up()?
>
> Kind regards
> Uffe
>
>>
>> Reported-by: Xiao Yao <xiaoyao@...k-chips.com>
>> Signed-off-by: Shawn Lin <shawn.lin@...k-chips.com>
>> ---
>>
>>  drivers/mmc/core/mmc.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
>> index 3163bb9..989d37e 100644
>> --- a/drivers/mmc/core/mmc.c
>> +++ b/drivers/mmc/core/mmc.c
>> @@ -1282,6 +1282,8 @@ static int mmc_select_hs400es(struct mmc_card *card)
>>         if (err)
>>                 goto out_err;
>>
>> +       mmc_set_clock(host, card->ext_csd.hs_max_dtr);
>> +
>>         err = mmc_switch_status(card);
>>         if (err)
>>                 goto out_err;
>> --
>> 2.3.7
>>
>>
>
>
>


-- 
Best Regards
Shawn Lin