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, 8 Jun 2023 17:53:04 +0200
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Chevron Li <chevron_li@....com>
Cc:     adrian.hunter@...el.com, linux-mmc@...r.kernel.org,
        linux-kernel@...r.kernel.org, shirley.her@...hubtech.com,
        xiaoguang.yu@...hubtech.com, shaper.liu@...hubtech.com,
        justin.wang@...hubtech.com, Chevron Li <chevron.li@...hubtech.com>
Subject: Re: [PATCH V1 1/1] mmc: sdhci: fix DMA configure compatibility issue
 when 64bit DMA mode is used.

On Tue, 23 May 2023 at 13:12, Chevron Li <chevron_li@....com> wrote:
>
> From: Chevron Li <chevron.li@...hubtech.com>
>
> Bayhub SD host has hardware limitation:
> 1.The upper 32bit address is inhibited to be written at SD Host Register
>   [03E][13]=0 (32bits addressing) mode, is admitted to be written only at
>   SD Host Register [03E][13]=1 (64bits addressing) mode.
> 2.Because of above item#1, need to configure SD Host Register [03E][13] to
>   1(64bits addressing mode) before set 64bit ADMA system address's higher
>   32bits SD Host Register [05F~05C] if 64 bits addressing mode is used.
>
> The hardware limitation is reasonable for below reasons:
> 1.Normal flow should set DMA working mode first, then do
>   DMA-transfer-related configuration, such as system address.
> 2.The hardware limitation may avoid the software to configure wrong higher
>   32bit address at 32bits addressing mode although it is redundant.
>
> The change that set 32bits/64bits addressing mode before set ADMA address,
>   has no side-effect to other host IPs for below reason:
> The setting order is reasonable and standard: DMA Mode setting first and
>   then DMA address setting. It meets all DMA setting sequence.
>
> Signed-off-by: Chevron Li <chevron.li@...hubtech.com>

Applied for next, thanks!

Is this material for stable kernels too, as it fixes a real problem, no?

Kind regards
Uffe


> ---
> Change in V1:
> Set dma mode configure before set dma address
> ---
>  drivers/mmc/host/sdhci.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 3241916141d7..ff41aa56564e 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1167,6 +1167,8 @@ static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_command *cmd)
>                 }
>         }
>
> +       sdhci_config_dma(host);
> +
>         if (host->flags & SDHCI_REQ_USE_DMA) {
>                 int sg_cnt = sdhci_pre_dma_transfer(host, data, COOKIE_MAPPED);
>
> @@ -1186,8 +1188,6 @@ static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_command *cmd)
>                 }
>         }
>
> -       sdhci_config_dma(host);
> -
>         if (!(host->flags & SDHCI_REQ_USE_DMA)) {
>                 int flags;
>
>
> base-commit: cc3c44c9fda264c6d401be04e95449a57c1231c6
> --
> 2.25.1
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ