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

[Arnd Bergmann]

On Fri, Oct 13, 2017 at 10:28 PM, Cyrille Pitchen
<cyrille.pitchen at wedev4u.fr> wrote:
> Hi Arnd,
>
> + Nicolas Ferre
>
> Le 01/08/2017 à 22:10, Arnd Bergmann a écrit :
>> On Tue, Aug 1, 2017 at 9:41 PM, Cyrille Pitchen
>> <cyrille.pitchen at wedev4u.fr> 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 :)
>>
>
> Bad news:
>
> I've just tested this patch, applied onto the spi-nor/next branch of
> l2-mtd (based on 4.14.0-rc4), with a sama5d2 xplained board + Macronix
> MX25L25673G Quad SPI memory but it fails on the very first SPI command,
> Read JEDEC ID (9Fh):
>
> atmel_qspi f0020000.spi: unrecognized JEDEC id bytes: c2, 20, 20
> atmel_qspi: probe of f0020000.spi failed with error -2

Ah, too bad. Should we just add the !ARCH_EBSA110 dependency
then?

       Arnd