On Fri, Jun 21, 2019 at 9:55:11, Arnd Bergmann [off-list ref] wrote:

On Fri, Jun 21, 2019 at 10:42 AM Gustavo Pimentel
[off-list ref] wrote:

quoted

On Mon, Jun 17, 2019 at 14:17:47, Arnd Bergmann [off-list ref] wrote:

quoted

When building with 'make C=1', sparse reports an endianess bug:

I didn't know that option.

quoted

drivers/dma/dw-edma/dw-edma-v0-debugfs.c:60:30: warning: cast removes address space of expression
drivers/dma/dw-edma/dw-edma-v0-debugfs.c:86:24: warning: incorrect type in argument 1 (different address spaces)
drivers/dma/dw-edma/dw-edma-v0-debugfs.c:86:24:    expected void const volatile [noderef] <asn:2>*addr
drivers/dma/dw-edma/dw-edma-v0-debugfs.c:86:24:    got void *[assigned] ptr
drivers/dma/dw-edma/dw-edma-v0-debugfs.c:86:24: warning: incorrect type in argument 1 (different address spaces)
drivers/dma/dw-edma/dw-edma-v0-debugfs.c:86:24:    expected void const volatile [noderef] <asn:2>*addr
drivers/dma/dw-edma/dw-edma-v0-debugfs.c:86:24:    got void *[assigned] ptr
drivers/dma/dw-edma/dw-edma-v0-debugfs.c:86:24: warning: incorrect type in argument 1 (different address spaces)
drivers/dma/dw-edma/dw-edma-v0-debugfs.c:86:24:    expected void const volatile [noderef] <asn:2>*addr
drivers/dma/dw-edma/dw-edma-v0-debugfs.c:86:24:    got void *[assigned] ptr

The current code is clearly wrong, as it passes an endian-swapped word
into a register function where it gets swapped again. I assume that this

Sorry I didn't catch this, endianness-swapped word into a register
function where it gets swapped again?
Where?

See dw_edma_v0_core_write_chunk()

                sar = cpu_to_le64(child->sar);
                SET_LL(&lli[i].sar_low, lower_32_bits(sar));
                SET_LL(&lli[i].sar_high, upper_32_bits(sar));

SET_LL() expands to writel(), which does a cpu_to_le32() swap.
(the swap  gets left out on architectures that are little-endian only)

That's right! I didn't look inside of writel().

quoted

quoted

diff --git a/drivers/dma/dw-edma/dw-edma-v0-core.c b/drivers/dma/dw-edma/dw-edma-v0-core.c
index 97e3fd41c8a8..d670ebcc37b3 100644
--- a/drivers/dma/dw-edma/dw-edma-v0-core.c
+++ b/drivers/dma/dw-edma/dw-edma-v0-core.c

@@ -195,7 +195,7 @@ static void dw_edma_v0_core_write_chunk(struct dw_edma_chunk *chunk)
      struct dw_edma_v0_lli __iomem *lli;
      struct dw_edma_v0_llp __iomem *llp;
      u32 control = 0, i = 0;
-     u64 sar, dar, addr;
+     uintptr_t sar, dar, addr;

Will this type assure variables sar, dar and addr are 64 bits?

No, just as long as a pointer. I somehow misread these as
referring to a kernel pointer, but got that part wrong. The
local variables can just be dropped then, just use
lower_32_bits(child->sar)) etc.

quoted

quoted

      int j;

      lli = chunk->ll_region.vaddr;

@@ -214,11 +214,11 @@ static void dw_edma_v0_core_write_chunk(struct dw_edma_chunk *chunk)
              /* Transfer size */
              SET_LL(&lli[i].transfer_size, child->sz);
              /* SAR - low, high */
-             sar = cpu_to_le64(child->sar);
+             sar = (uintptr_t)child->sar;

Assuming the host is a big-endian machine and the eDMA on the endpoint
strictly requires the address to be little endian.
By not using cpu_to_le64(), the address to be written on the eDMA will be
in big-endian format, right? If so, that will break the driver.

No, because of the double-swap you are writing a big-endian address
here, which is the bug I am referring to.

After doing a quick exercise I realize that cpu_to_le64() shouldn't be 
there at all like you said. Since I only tested this driver on 
little-endian architecture system this issue wasn't visible at all.

     Arnd