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

[Mark Rutland]

On Tue, Jun 08, 2021 at 02:36:26PM +0200, Neil Armstrong wrote:
> On 08/06/2021 14:21, Marek Szyprowski wrote:
> > On 08.06.2021 13:37, Robin Murphy wrote:
> >> On 2021-06-08 12:15, Marek Szyprowski wrote:
> >>> 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.

[...]

> >>> 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.