linux-kernel - Re: [PATCH] mmc: sdhci-xenon: Fix 2G limitation on AC5 SoC

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: <20220727164532.GA19351@plvision.eu>
Date:   Wed, 27 Jul 2022 19:45:32 +0300
From:   Vadym Kochan <vadym.kochan@...ision.eu>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     Hu Ziji <huziji@...vell.com>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        linux-mmc@...r.kernel.org, linux-kernel@...r.kernel.org,
        Elad Nachman <enachman@...vell.com>
Subject: Re: [PATCH] mmc: sdhci-xenon: Fix 2G limitation on AC5 SoC

Hi Florian,

On Tue, Jul 26, 2022 at 10:37:46AM -0700, Florian Fainelli wrote:
> On 7/26/22 10:07, Vadym Kochan wrote:
> > From: Elad Nachman <enachman@...vell.com>
> > 
> > There is a limitation on AC5 SoC that mmc controller
> > can't have DMA access over 2G memory.
> > 
> > Signed-off-by: Elad Nachman <enachman@...vell.com>
> > Signed-off-by: Vadym Kochan <vadym.kochan@...ision.eu>
> > ---
> >  drivers/mmc/host/sdhci-xenon.c | 13 +++++++++++++
> >  1 file changed, 13 insertions(+)
> > 
> > diff --git a/drivers/mmc/host/sdhci-xenon.c b/drivers/mmc/host/sdhci-xenon.c
> > index 08e838400b52..666d06b58564 100644
> > --- a/drivers/mmc/host/sdhci-xenon.c
> > +++ b/drivers/mmc/host/sdhci-xenon.c
> > @@ -18,6 +18,7 @@
> >  #include <linux/of.h>
> >  #include <linux/pm.h>
> >  #include <linux/pm_runtime.h>
> > +#include <linux/mm.h>
> >  
> >  #include "sdhci-pltfm.h"
> >  #include "sdhci-xenon.h"
> > @@ -422,6 +423,8 @@ static int xenon_probe_params(struct platform_device *pdev)
> >  	struct xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
> >  	u32 sdhc_id, nr_sdhc;
> >  	u32 tuning_count;
> > +	struct device_node *np = pdev->dev.of_node;
> > +	struct sysinfo si;
> >  
> >  	/* Disable HS200 on Armada AP806 */
> >  	if (priv->hw_version == XENON_AP806)
> > @@ -450,6 +453,15 @@ static int xenon_probe_params(struct platform_device *pdev)
> >  	}
> >  	priv->tuning_count = tuning_count;
> >  
> > +	si_meminfo(&si);
> > +
> > +	if (of_device_is_compatible(np, "marvell,ac5-sdhci") &&
> > +	    ((si.totalram * si.mem_unit) > 0x80000000 /*2G*/)) {
> 
> Why not limit the DMA mask of the device and ensure, that bounce buffers get used so you can still do DMA?
> 
> Also, you ought to be able to describe that limitation using Device Tree (assuming this is an option) and declaring a dedicated bus node for the SDHCI controller and providing a suitable dma-ranges property, see: arch/arm/boot/dts/bcm2711.dtsi and the 'soc' node for such examples.
> 
> 

Do I understand correctly that the swiotlb will be used in case DMA
engine could not map the page in the specified range (limited by dma-ranges or
dma-mask) ?

> 
> > +		host->quirks |= SDHCI_QUIRK_BROKEN_DMA;
> > +		host->quirks |= SDHCI_QUIRK_BROKEN_ADMA;
> > +		dev_info(mmc_dev(mmc), "Disabling DMA because of 2GB DMA access limit.\n");
> > +	}
> > +
> >  	return xenon_phy_parse_params(dev, host);
> >  }
> >  
> > @@ -682,6 +694,7 @@ static const struct of_device_id sdhci_xenon_dt_ids[] = {
> >  	{ .compatible = "marvell,armada-ap807-sdhci", .data = (void *)XENON_AP807},
> >  	{ .compatible = "marvell,armada-cp110-sdhci", .data =  (void *)XENON_CP110},
> >  	{ .compatible = "marvell,armada-3700-sdhci", .data =  (void *)XENON_A3700},
> > +	{ .compatible = "marvell,ac5-sdhci", .data = (void *)XENON_AP806},
> >  	{}
> >  };
> >  MODULE_DEVICE_TABLE(of, sdhci_xenon_dt_ids);
> 
> 
> -- 
> Florian

Thanks,