linux-kernel - Re: [PATCH v2] mmc: core: Don't set HS200 clock rate prematurely

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] [day] [month] [year] [list]

Date:   Fri, 22 Apr 2022 11:10:32 +0200
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Brian Norris <briannorris@...omium.org>
Cc:     Shawn Lin <shawn.lin@...k-chips.com>, linux-mmc@...r.kernel.org,
        Douglas Anderson <dianders@...omium.org>,
        Luca Weiss <luca@...tu.xyz>, linux-kernel@...r.kernel.org,
        Heiner Kallweit <hkallweit1@...il.com>,
        Adrian Hunter <adrian.hunter@...el.com>
Subject: Re: [PATCH v2] mmc: core: Don't set HS200 clock rate prematurely

On Fri, 22 Apr 2022 at 02:23, Brian Norris <briannorris@...omium.org> wrote:
>
> Commit 1c7ec586fe55 ("mmc: core: Set HS clock speed before sending HS
> CMD13") fixes problems with certain eMMC, but introduced new ones with
> others:
>
>   qcom-msm8974-fairphone-fp2:
>
>   [    1.868608] mmc0: SDHCI controller on f9824900.sdhci [f9824900.sdhci] using ADMA 64-bit
>   [    1.925220] mmc0: mmc_select_hs200 failed, error -110
>   [    1.925285] mmc0: error -110 whilst initialising MMC card
>
> It appears we've overshot the acceptable clock rate here; while JESD84
> suggests that we can bump to 52 MHz before switching (CMD6) to HS400, it
> does *not* say we can switch to 200 MHz before switching to HS200 (see
> page 45 / table 28). Use the HS bounds (typically 52 MHz) instead of the
> HS200 bounds (which are only applicable after we successfully switch).
>
> Link: https://lore.kernel.org/lkml/11962455.O9o76ZdvQC@g550jk/
> Fixes: 1c7ec586fe55 ("mmc: core: Set HS clock speed before sending HS CMD13")
> Reported-by: Luca Weiss <luca@...tu.xyz>
> Signed-off-by: Brian Norris <briannorris@...omium.org>

Rather than applying this incremental patch, I decided to drop the
offending commit from my branch. Please submit a new version of that
patch and make sure to incorporate credits and information provided by
Luca, as a part of the new commit message.

The main reason for this step is that I think we want a clean patch
that we can use for stable kernels too.

Moreover, this also means you can drop the changes in mmc_set_clock()
that was introduced in 1c7ec586fe55().

Kind regards
Uffe

> ---
> Apologies for the quick resend; I fumbled the commit/send, even though I
> had already updated the comments...
>
> Changes in v2:
>  * Updated comments
>
>  drivers/mmc/core/mmc.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index 9ab915b5737a..82ca62c8669c 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -1485,13 +1485,15 @@ static int mmc_select_hs200(struct mmc_card *card)
>                         goto err;
>
>                 /*
> -                * Bump to HS200 timing and frequency. Some cards don't
> -                * handle SEND_STATUS reliably at the initial frequency.
> +                * Bump to HS timing and frequency. Some cards don't handle
> +                * SEND_STATUS reliably at the initial frequency.
> +                * NB: We can't move to full (HS200) speeds until after we've
> +                * successfully switched over.
>                  */
>                 old_timing = host->ios.timing;
>                 old_clock = host->ios.clock;
>                 mmc_set_timing(host, MMC_TIMING_MMC_HS200);
> -               mmc_set_bus_speed(card);
> +               mmc_set_clock(card->host, card->ext_csd.hs_max_dtr);
>
>                 /*
>                  * For HS200, CRC errors are not a reliable way to know the
> --
> 2.36.0.rc2.479.g8af0fa9b8e-goog
>