Re: [PATCH] [RFC] mtd: atmel-quadspi: fix build issues

[Arnd Bergmann]

On Tue, Aug 1, 2017 at 9:41 PM, Cyrille Pitchen
<cyrille.pitchen@xxxxxxxxxx> wrote:
> Le 22/07/2017 Ã 00:21, Arnd Bergmann a Ãcrit :

>> --- a/drivers/mtd/spi-nor/atmel-quadspi.c
>> +++ b/drivers/mtd/spi-nor/atmel-quadspi.c
>> @@ -208,9 +208,9 @@ static int atmel_qspi_run_transfer(struct atmel_qspi *aq,
>>       if (cmd->enable.bits.address)
>>               ahb_mem += cmd->address;
>>       if (cmd->tx_buf)
>> -             _memcpy_toio(ahb_mem, cmd->tx_buf, cmd->buf_len);
>> +             memcpy_toio(ahb_mem, cmd->tx_buf, cmd->buf_len);
>>       else
>> -             _memcpy_fromio(cmd->rx_buf, ahb_mem, cmd->buf_len);
>> +             memcpy_fromio(cmd->rx_buf, ahb_mem, cmd->buf_len);
>>
>
> At least on AT91 platforms and likely on most ARM boards,
> memcpy_fromio == memcpy_toio == memcpy.

Just to give more background, it's a bit more complicated than this:

On big-endian kernels, memcpy_fromio/memcpy_toio are
always defined as _memcpy_fromio/_memcpy_toio so we
do byte load/store operations in the correct order, while
little-endian kernels have the optimized mmiocpy() that redirects
to memcpy(). This is true for all ARM platforms other than EBSA110
IIRC.

Also, mmiocpy is an exported symbol that aliases to the external
memcpy definition, but we can't call memcpy directly, because gcc
knows how to inline calls to memcpy() and replace them by direct
load/store instructions that might be unaligned and trap on uncached
mmio areas.

> I got some sama5d2 hardware last week, so I'll try to test your patch
> within few days because as you said maybe memcpy() was broken when I
> developed this driver at first but now memcpy() is likely to have been
> fixed so it might be interesting to get rid of _memcpy_fromio() and
> _memcpy_toio() because this is not the first time those 2 functions have
> created issues when building the Atmel Quad SPI driver on other platforms.
>
> So thanks for you're patch, I'll give it a try :)

Ok, thanks.

       Arnd