[PATCH 0/3] Fix sdhci-of-esdhc DMA coherency

[PATCH 0/3] Fix sdhci-of-esdhc DMA coherency

[Russell King - ARM Linux admin]

Hi,

The following patch set is a result of looking at the ADMA errors
observed on SolidRun's LX2160A board, caused by coherency mismatch
between DT and hardware.

The first patch improves the debugging by dumping the ADMA table
using the DMA address, which can be compared with the DMA address
reported in the register dump.  It also prints the interrupt status
that we read, whereas the register dump contains the _cleared_
interrupt status.

The second patch modifies sdhci-of-esdhc to set the DMA snoop bit
depending on whether DT marks the device as coherent or not.  With
this patch applied, driver will now set the hardware to match the
contents of DT, rather than always DMA snooping.  As explained by
Robin, if the hardware snoops the CPU caches, but the DMA API layer
does not expect this, the hardware can read stale data.  The hardware
state and the DMA API must always agree wrt this, for the sake of
data integrity.  Mismatch risks substantial filesystem corruption.

The third patch marks the LX2160A esdhc devices as dma-coherent.
Other users of the driver are not touched; I do not have the
information to know whether DMA snooping (coherency) is available
on other SoCs using this driver.  However, given the risk of
filesystem corruption, it is important no matter what that the
DMA API layer and the hardware agree - even if it means defaulting
to being non-coherent.

 arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi |  2 ++
 drivers/mmc/host/sdhci-of-esdhc.c              |  7 ++++++-
 drivers/mmc/host/sdhci.c                       | 15 ++++++++++-----
 3 files changed, 18 insertions(+), 6 deletions(-)

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

RE: [PATCH 2/3] mmc: sdhci-of-esdhc: set DMA snooping based on DMA coherence

[Y.b. Lu]

Hi Russell,

Recently I got eSDHC ADMA issue on PowerPC T2080 platform. After checking, the issue is related to this patch.
This patch was to make eSDHC DMA SNOOP bit set per dma-coherent. That resolved issue on LX2160A ARM64 platform.
However on T2080, we are facing similar issue again. It didn't have dma-coherent in dts.
Adding dma-coherent in dts, or reverting the patch could resolve the problem.

Would you please help to have a look at it too? Thanks:)

mmc0: ADMA error: 0x02000000
mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
mmc0: sdhci: Sys addr:  0x00000000 | Version:  0x00002002
mmc0: sdhci: Blk size:  0x00000008 | Blk cnt:  0x00000001
mmc0: sdhci: Argument:  0x00000000 | Trn mode: 0x00000013
NET: Registered protocol family 10
mmc0: sdhci: Present:   0x01fd020a | Host ctl: 0x00000038
mmc0: sdhci: Power:     0x00000003 | Blk gap:  0x00000000
mmc0: sdhci: Wake-up:   0x00000000 | Clock:    0x000020b8
mmc0: sdhci: Timeout:   0x00000003 | Int stat: 0x00000001
mmc0: sdhci: Int enab:  0x037f100f | Sig enab: 0x037f100b
mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00002002
mmc0: sdhci: Caps:      0x34fa0000 | Caps_1:   0x0000af00
mmc0: sdhci: Cmd:       0x0000333a | Max curr: 0x00000000
mmc0: sdhci: Resp[0]:   0x00000920 | Resp[1]:  0x003b3733
mmc0: sdhci: Resp[2]:   0x325b5900 | Resp[3]:  0x3f400e00
mmc0: sdhci: Host ctl2: 0x00000000
mmc0: sdhci: ADMA Err:  0x0000000d | ADMA Ptr: 0x00000000f35ad20c
mmc0: sdhci: ============================================
mmc0: sdhci: f35ad200: DMA 0x00000000f3587710, LEN 0x0008, Attr=0x23
mmc0: error -5 whilst initialising SD card

Best regards,
Yangbo Lu


> -----Original Message-----
> From: Russell King <rmk@armlinux.org.uk> On Behalf Of Russell King
> Sent: Sunday, September 22, 2019 6:27 PM
> To: Robin Murphy <robin.murphy@arm.com>; dann frazier
> <dann.frazier@canonical.com>; Will Deacon <will.deacon@arm.com>; Nicolin
> Chen <nicoleotsuka@gmail.com>; Y.b. Lu <yangbo.lu@nxp.com>; Christoph
> Hellwig <hch@lst.de>
> Cc: Adrian Hunter <adrian.hunter@intel.com>; Ulf Hansson
> <ulf.hansson@linaro.org>; linux-mmc@vger.kernel.org
> Subject: [PATCH 2/3] mmc: sdhci-of-esdhc: set DMA snooping based on DMA
> coherence
> 
> We must not unconditionally set the DMA snoop bit; if the DMA API is
> assuming that the device is not DMA coherent, and the device snoops the
> CPU caches, the device can see stale cache lines brought in by
> speculative prefetch.
> 
> This leads to the device seeing stale data, potentially resulting in
> corrupted data transfers.  Commonly, this results in a descriptor fetch
> error such as:
> 
> mmc0: ADMA error
> mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
> mmc0: sdhci: Sys addr:  0x00000000 | Version:  0x00002202
> mmc0: sdhci: Blk size:  0x00000008 | Blk cnt:  0x00000001
> mmc0: sdhci: Argument:  0x00000000 | Trn mode: 0x00000013
> mmc0: sdhci: Present:   0x01f50008 | Host ctl: 0x00000038
> mmc0: sdhci: Power:     0x00000003 | Blk gap:  0x00000000
> mmc0: sdhci: Wake-up:   0x00000000 | Clock:    0x000040d8
> mmc0: sdhci: Timeout:   0x00000003 | Int stat: 0x00000001
> mmc0: sdhci: Int enab:  0x037f108f | Sig enab: 0x037f108b
> mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00002202
> mmc0: sdhci: Caps:      0x35fa0000 | Caps_1:   0x0000af00
> mmc0: sdhci: Cmd:       0x0000333a | Max curr: 0x00000000
> mmc0: sdhci: Resp[0]:   0x00000920 | Resp[1]:  0x001d8a33
> mmc0: sdhci: Resp[2]:   0x325b5900 | Resp[3]:  0x3f400e00
> mmc0: sdhci: Host ctl2: 0x00000000
> mmc0: sdhci: ADMA Err:  0x00000009 | ADMA Ptr: 0x000000236d43820c
> mmc0: sdhci: ============================================
> mmc0: error -5 whilst initialising SD card
> 
> but can lead to other errors, and potentially direct the SDHCI
> controller to read/write data to other memory locations (e.g. if a valid
> descriptor is visible to the device in a stale cache line.)
> 
> Fix this by ensuring that the DMA snoop bit corresponds with the
> behaviour of the DMA API.  Since the driver currently only supports DT,
> use of_dma_is_coherent().  Note that device_get_dma_attr() can not be
> used as that risks re-introducing this bug if/when the driver is
> converted to ACPI.
> 
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
>  drivers/mmc/host/sdhci-of-esdhc.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/host/sdhci-of-esdhc.c
> b/drivers/mmc/host/sdhci-of-esdhc.c
> index 4dd43b1adf2c..74de5e8c45c8 100644
> --- a/drivers/mmc/host/sdhci-of-esdhc.c
> +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> @@ -495,7 +495,12 @@ static int esdhc_of_enable_dma(struct sdhci_host
> *host)
>  		dma_set_mask_and_coherent(dev, DMA_BIT_MASK(40));
> 
>  	value = sdhci_readl(host, ESDHC_DMA_SYSCTL);
> -	value |= ESDHC_DMA_SNOOP;
> +
> +	if (of_dma_is_coherent(dev->of_node))
> +		value |= ESDHC_DMA_SNOOP;
> +	else
> +		value &= ~ESDHC_DMA_SNOOP;
> +
>  	sdhci_writel(host, value, ESDHC_DMA_SYSCTL);
>  	return 0;
>  }
> --
> 2.7.4

Re: [PATCH 2/3] mmc: sdhci-of-esdhc: set DMA snooping based on DMA coherence

[Russell King - ARM Linux admin]

On Mon, Jan 20, 2020 at 10:09:00AM +0000, Y.b. Lu wrote:
> Hi Russell,
> 
> Recently I got eSDHC ADMA issue on PowerPC T2080 platform. After checking, the issue is related to this patch.
> This patch was to make eSDHC DMA SNOOP bit set per dma-coherent. That resolved issue on LX2160A ARM64 platform.
> However on T2080, we are facing similar issue again. It didn't have dma-coherent in dts.
> Adding dma-coherent in dts, or reverting the patch could resolve the problem.
> 
> Would you please help to have a look at it too? Thanks:)

All aspects of this was discussed extensively by many parties, and as
far as I remember, no conclusion was reached - the discussion became
rather unproductive, so I walked away from it.

I've more or less washed my hands of this in disgust that no way
forward can be found, not even reverting the patch (and then I'll
just carry the patch locally, so at least my machines work - shame
for other ARM64 folk trying to use the LX2160A.)

> 
> mmc0: ADMA error: 0x02000000
> mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
> mmc0: sdhci: Sys addr:  0x00000000 | Version:  0x00002002
> mmc0: sdhci: Blk size:  0x00000008 | Blk cnt:  0x00000001
> mmc0: sdhci: Argument:  0x00000000 | Trn mode: 0x00000013
> NET: Registered protocol family 10
> mmc0: sdhci: Present:   0x01fd020a | Host ctl: 0x00000038
> mmc0: sdhci: Power:     0x00000003 | Blk gap:  0x00000000
> mmc0: sdhci: Wake-up:   0x00000000 | Clock:    0x000020b8
> mmc0: sdhci: Timeout:   0x00000003 | Int stat: 0x00000001
> mmc0: sdhci: Int enab:  0x037f100f | Sig enab: 0x037f100b
> mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00002002
> mmc0: sdhci: Caps:      0x34fa0000 | Caps_1:   0x0000af00
> mmc0: sdhci: Cmd:       0x0000333a | Max curr: 0x00000000
> mmc0: sdhci: Resp[0]:   0x00000920 | Resp[1]:  0x003b3733
> mmc0: sdhci: Resp[2]:   0x325b5900 | Resp[3]:  0x3f400e00
> mmc0: sdhci: Host ctl2: 0x00000000
> mmc0: sdhci: ADMA Err:  0x0000000d | ADMA Ptr: 0x00000000f35ad20c
> mmc0: sdhci: ============================================
> mmc0: sdhci: f35ad200: DMA 0x00000000f3587710, LEN 0x0008, Attr=0x23
> mmc0: error -5 whilst initialising SD card
> 
> Best regards,
> Yangbo Lu
> 
> 
> > -----Original Message-----
> > From: Russell King <rmk@armlinux.org.uk> On Behalf Of Russell King
> > Sent: Sunday, September 22, 2019 6:27 PM
> > To: Robin Murphy <robin.murphy@arm.com>; dann frazier
> > <dann.frazier@canonical.com>; Will Deacon <will.deacon@arm.com>; Nicolin
> > Chen <nicoleotsuka@gmail.com>; Y.b. Lu <yangbo.lu@nxp.com>; Christoph
> > Hellwig <hch@lst.de>
> > Cc: Adrian Hunter <adrian.hunter@intel.com>; Ulf Hansson
> > <ulf.hansson@linaro.org>; linux-mmc@vger.kernel.org
> > Subject: [PATCH 2/3] mmc: sdhci-of-esdhc: set DMA snooping based on DMA
> > coherence
> > 
> > We must not unconditionally set the DMA snoop bit; if the DMA API is
> > assuming that the device is not DMA coherent, and the device snoops the
> > CPU caches, the device can see stale cache lines brought in by
> > speculative prefetch.
> > 
> > This leads to the device seeing stale data, potentially resulting in
> > corrupted data transfers.  Commonly, this results in a descriptor fetch
> > error such as:
> > 
> > mmc0: ADMA error
> > mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
> > mmc0: sdhci: Sys addr:  0x00000000 | Version:  0x00002202
> > mmc0: sdhci: Blk size:  0x00000008 | Blk cnt:  0x00000001
> > mmc0: sdhci: Argument:  0x00000000 | Trn mode: 0x00000013
> > mmc0: sdhci: Present:   0x01f50008 | Host ctl: 0x00000038
> > mmc0: sdhci: Power:     0x00000003 | Blk gap:  0x00000000
> > mmc0: sdhci: Wake-up:   0x00000000 | Clock:    0x000040d8
> > mmc0: sdhci: Timeout:   0x00000003 | Int stat: 0x00000001
> > mmc0: sdhci: Int enab:  0x037f108f | Sig enab: 0x037f108b
> > mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00002202
> > mmc0: sdhci: Caps:      0x35fa0000 | Caps_1:   0x0000af00
> > mmc0: sdhci: Cmd:       0x0000333a | Max curr: 0x00000000
> > mmc0: sdhci: Resp[0]:   0x00000920 | Resp[1]:  0x001d8a33
> > mmc0: sdhci: Resp[2]:   0x325b5900 | Resp[3]:  0x3f400e00
> > mmc0: sdhci: Host ctl2: 0x00000000
> > mmc0: sdhci: ADMA Err:  0x00000009 | ADMA Ptr: 0x000000236d43820c
> > mmc0: sdhci: ============================================
> > mmc0: error -5 whilst initialising SD card
> > 
> > but can lead to other errors, and potentially direct the SDHCI
> > controller to read/write data to other memory locations (e.g. if a valid
> > descriptor is visible to the device in a stale cache line.)
> > 
> > Fix this by ensuring that the DMA snoop bit corresponds with the
> > behaviour of the DMA API.  Since the driver currently only supports DT,
> > use of_dma_is_coherent().  Note that device_get_dma_attr() can not be
> > used as that risks re-introducing this bug if/when the driver is
> > converted to ACPI.
> > 
> > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > ---
> >  drivers/mmc/host/sdhci-of-esdhc.c | 7 ++++++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/mmc/host/sdhci-of-esdhc.c
> > b/drivers/mmc/host/sdhci-of-esdhc.c
> > index 4dd43b1adf2c..74de5e8c45c8 100644
> > --- a/drivers/mmc/host/sdhci-of-esdhc.c
> > +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> > @@ -495,7 +495,12 @@ static int esdhc_of_enable_dma(struct sdhci_host
> > *host)
> >  		dma_set_mask_and_coherent(dev, DMA_BIT_MASK(40));
> > 
> >  	value = sdhci_readl(host, ESDHC_DMA_SYSCTL);
> > -	value |= ESDHC_DMA_SNOOP;
> > +
> > +	if (of_dma_is_coherent(dev->of_node))
> > +		value |= ESDHC_DMA_SNOOP;
> > +	else
> > +		value &= ~ESDHC_DMA_SNOOP;
> > +
> >  	sdhci_writel(host, value, ESDHC_DMA_SYSCTL);
> >  	return 0;
> >  }
> > --
> > 2.7.4
> 

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

Re: [PATCH 2/3] mmc: sdhci-of-esdhc: set DMA snooping based on DMA coherence

[Robin Murphy]

On 20/01/2020 10:09 am, Y.b. Lu wrote:
> Hi Russell,
> 
> Recently I got eSDHC ADMA issue on PowerPC T2080 platform. After checking, the issue is related to this patch.
> This patch was to make eSDHC DMA SNOOP bit set per dma-coherent. That resolved issue on LX2160A ARM64 platform.
> However on T2080, we are facing similar issue again. It didn't have dma-coherent in dts.
> Adding dma-coherent in dts, or reverting the patch could resolve the problem.

Arguably updating the DTS would be the most accurate option, since it 
would be describing the hardware more correctly, however if there are 
reasons for that not being sufficient (e.g. DTBs baked into firmware, or 
worries of confusing some other DT consumer) then something like the 
below seems reasonable (albeit a little crude) IMO.

Robin.

----->8-----
 From fafad319893b4168fcccc5445543caf876a0be2d Mon Sep 17 00:00:00 2001
Message-Id: 
<fafad319893b4168fcccc5445543caf876a0be2d.1579526755.git.robin.murphy@arm.com>
From: Robin Murphy <robin.murphy@arm.com>
Date: Mon, 20 Jan 2020 13:11:59 +0000
Subject: [PATCH] mmc: sdhci-of-esdhc: Restore coherency for PPC platforms

Historically, not all PPC platforms have supported per-device coherency,
and some may rely on platform-level assumptions rather than explicitly
specifying the "dma-coherent" propert in their DT. Although the eSDHC
driver needs to tie in to per-device coherency to work correctly on
arm/arm64 platforms, this has apparently caused problems for PPC, so
restore the previous behaviour there with a special case.

Fixes: 121bd08b029e ("mmc: sdhci-of-esdhc: set DMA snooping based on DMA 
coherence")
Reported-by: Yangbo Lu <yangbo.lu@nxp.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
  drivers/mmc/host/sdhci-of-esdhc.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-of-esdhc.c 
b/drivers/mmc/host/sdhci-of-esdhc.c
index 500f70a6ee42..a2599368b2bd 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -527,7 +527,8 @@ static int esdhc_of_enable_dma(struct sdhci_host *host)

  	value = sdhci_readl(host, ESDHC_DMA_SYSCTL);

-	if (of_dma_is_coherent(dev->of_node))
+	/* Historically, PPC has always assumed coherency here */
+	if (IS_ENABLED(CONFIG_PPC) || of_dma_is_coherent(dev->of_node))
  		value |= ESDHC_DMA_SNOOP;
  	else
  		value &= ~ESDHC_DMA_SNOOP;
-- 
2.23.0.dirty

RE: [PATCH 2/3] mmc: sdhci-of-esdhc: set DMA snooping based on DMA coherence

[Y.b. Lu]

Hi Robin,

Thanks lot for your suggestion. I prefer your fix-up patch to treat PowerPC as a special case.

Hi Adrian and Uffe,

Do you think it is ok? Should I help to re-send that patch to mmc mailing list for reviewing.
Thanks.

Best regards,
Yangbo Lu

> -----Original Message-----
> From: Robin Murphy <robin.murphy@arm.com>
> Sent: Monday, January 20, 2020 9:34 PM
> To: Y.b. Lu <yangbo.lu@nxp.com>; Russell King <rmk+kernel@armlinux.org.uk>
> Cc: Adrian Hunter <adrian.hunter@intel.com>; Ulf Hansson
> <ulf.hansson@linaro.org>; linux-mmc@vger.kernel.org; dann frazier
> <dann.frazier@canonical.com>; Will Deacon <will.deacon@arm.com>; Nicolin
> Chen <nicoleotsuka@gmail.com>; Christoph Hellwig <hch@lst.de>
> Subject: Re: [PATCH 2/3] mmc: sdhci-of-esdhc: set DMA snooping based on
> DMA coherence
> 
> On 20/01/2020 10:09 am, Y.b. Lu wrote:
> > Hi Russell,
> >
> > Recently I got eSDHC ADMA issue on PowerPC T2080 platform. After
> checking, the issue is related to this patch.
> > This patch was to make eSDHC DMA SNOOP bit set per dma-coherent. That
> resolved issue on LX2160A ARM64 platform.
> > However on T2080, we are facing similar issue again. It didn't have
> dma-coherent in dts.
> > Adding dma-coherent in dts, or reverting the patch could resolve the
> problem.
> 
> Arguably updating the DTS would be the most accurate option, since it
> would be describing the hardware more correctly, however if there are
> reasons for that not being sufficient (e.g. DTBs baked into firmware, or
> worries of confusing some other DT consumer) then something like the
> below seems reasonable (albeit a little crude) IMO.
> 
> Robin.
> 
> ----->8-----
>  From fafad319893b4168fcccc5445543caf876a0be2d Mon Sep 17 00:00:00
> 2001
> Message-Id:
> <fafad319893b4168fcccc5445543caf876a0be2d.1579526755.git.robin.murph
> y@arm.com>
> From: Robin Murphy <robin.murphy@arm.com>
> Date: Mon, 20 Jan 2020 13:11:59 +0000
> Subject: [PATCH] mmc: sdhci-of-esdhc: Restore coherency for PPC platforms
> 
> Historically, not all PPC platforms have supported per-device coherency,
> and some may rely on platform-level assumptions rather than explicitly
> specifying the "dma-coherent" propert in their DT. Although the eSDHC
> driver needs to tie in to per-device coherency to work correctly on
> arm/arm64 platforms, this has apparently caused problems for PPC, so
> restore the previous behaviour there with a special case.
> 
> Fixes: 121bd08b029e ("mmc: sdhci-of-esdhc: set DMA snooping based on
> DMA
> coherence")
> Reported-by: Yangbo Lu <yangbo.lu@nxp.com>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
>   drivers/mmc/host/sdhci-of-esdhc.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/host/sdhci-of-esdhc.c
> b/drivers/mmc/host/sdhci-of-esdhc.c
> index 500f70a6ee42..a2599368b2bd 100644
> --- a/drivers/mmc/host/sdhci-of-esdhc.c
> +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> @@ -527,7 +527,8 @@ static int esdhc_of_enable_dma(struct sdhci_host
> *host)
> 
>   	value = sdhci_readl(host, ESDHC_DMA_SYSCTL);
> 
> -	if (of_dma_is_coherent(dev->of_node))
> +	/* Historically, PPC has always assumed coherency here */
> +	if (IS_ENABLED(CONFIG_PPC) || of_dma_is_coherent(dev->of_node))
>   		value |= ESDHC_DMA_SNOOP;
>   	else
>   		value &= ~ESDHC_DMA_SNOOP;
> --
> 2.23.0.dirty

Re: [PATCH 2/3] mmc: sdhci-of-esdhc: set DMA snooping based on DMA coherence

[Ulf Hansson]

On Wed, 5 Feb 2020 at 06:56, Y.b. Lu <yangbo.lu@nxp.com> wrote:
>
> Hi Robin,
>
> Thanks lot for your suggestion. I prefer your fix-up patch to treat PowerPC as a special case.
>
> Hi Adrian and Uffe,
>
> Do you think it is ok? Should I help to re-send that patch to mmc mailing list for reviewing.
> Thanks.

commit dabf6b36b83a18d57e3d4b9d50544ed040d86255
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Sun Jan 26 22:52:47 2020 +1100
of: Add OF_DMA_DEFAULT_COHERENT & select it on powerpc

This one is already in Linus' tree, I suppose that is sufficient.

[...]

Kind regards
Uffe