linux-kernel - Re: [PATCH RFC 05/15] mmc: sunxi: Support MMC

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:	Thu, 21 Jan 2016 13:26:39 +0100
From:	Hans de Goede <hdegoede@...hat.com>
To:	Chen-Yu Tsai <wens@...e.org>
Cc:	Ulf Hansson <ulf.hansson@...aro.org>,
	Maxime Ripard <maxime.ripard@...e-electrons.com>,
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-sunxi <linux-sunxi@...glegroups.com>
Subject: Re: [PATCH RFC 05/15] mmc: sunxi: Support MMC_DDR52 timing modes

Hi,

On 21-01-16 12:55, Chen-Yu Tsai wrote:
> On Thu, Jan 21, 2016 at 7:14 PM, Hans de Goede <hdegoede@...hat.com> wrote:
>> Hi,
>>
>> On 21-01-16 06:26, Chen-Yu Tsai wrote:
>>>
>>> DDR transfer modes include UHS-1 DDR50 and MMC HS-DDR (or MMC_DDR52).
>>> Consider MMC_DDR52 when setting clock delays.
>>>
>>> Signed-off-by: Chen-Yu Tsai <wens@...e.org>
>>> ---
>>>    drivers/mmc/host/sunxi-mmc.c | 6 ++++--
>>>    1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
>>> index 4bec87458317..b403a2433eec 100644
>>> --- a/drivers/mmc/host/sunxi-mmc.c
>>> +++ b/drivers/mmc/host/sunxi-mmc.c
>>> @@ -687,7 +687,8 @@ static int sunxi_mmc_clk_set_rate(struct
>>> sunxi_mmc_host *host,
>>>                  oclk_dly = host->clk_delays[SDXC_CLK_25M].output;
>>>                  sclk_dly = host->clk_delays[SDXC_CLK_25M].sample;
>>>          } else if (rate <= 50000000) {
>>
>>
>> Shouldn't this be <= 52000000 then, considering that we may at one point get
>> some PLL setup where we may actually be able to do 52000000 for
>> MMC_TIMING_MMC_DDR52 ?
>
> Given that mmc->f_max = 50000000, the core will never try any clock rate higher
> than 50 MHz, and iirc clk_round_rate always rounds down. We could increase both
> numbers at the same time when we actually encounter such hardware.

I'm afraid that someone may increase mmc->f_max = 50000000 at one point without
adjusting the rate checks above at the same time, so lets update both of them now.

Regards,

Hans