Re: [PATCH v2 6/8] arm64: Import latest memcpy()/memmove() implementation

On Tue, Jun 08, 2021 at 02:36:26PM +0200, Neil Armstrong wrote:

On 08/06/2021 14:21, Marek Szyprowski wrote:

quoted

On 08.06.2021 13:37, Robin Murphy wrote:

quoted

On 2021-06-08 12:15, Marek Szyprowski wrote:

quoted

This patch landed recently in linux-next as commit 285133040e6c ("arm64:
Import latest memcpy()/memmove() implementation"). Sadly it causes
serious issues on Khadas VIM3 board. Reverting it on top of linux
next-20210607 (together with 6b8f648959e5 and resolving the conflict in
the Makefile) fixes the issue. Here is the kernel log:

Unable to handle kernel paging request at virtual address 
ffff8000136bd204
Mem abort info:
    ESR = 0x96000061
    EC = 0x25: DABT (current EL), IL = 32 bits
    SET = 0, FnV = 0
    EA = 0, S1PTW = 0
Data abort info:
    ISV = 0, ISS = 0x00000061

That's an alignment fault, which implies we're accessing something 
which isn't normal memory.

[...]

quoted

quoted

quoted

I hope that the above log helps fixing the issue. IIRC the SDHCI driver
on VIM3 board uses internal SRAM for transferring data (instead of DMA),
so the issue is somehow related to that.

Drivers shouldn't be using memcpy() on iomem mappings. Even if they 
happen to have got away with it sometimes ;)

Taking a quick look at that driver,

    host->bounce_buf = host->regs + SD_EMMC_SRAM_DATA_BUF_OFF;

is completely bogus, as Sparse will readily point out.

My bad, what's the correct way to copy data to an iomem mapping ?

We have memcpy_toio() and memcpy_fromio() for this.

Thanks,
Mark.

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic