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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <020801cc-9ac3-454b-3e31-25f9279ed7e8@wedev4u.fr>
Date:   Sun, 29 Oct 2017 20:49:26 +0100
From:   Cyrille Pitchen <cyrille.pitchen@...ev4u.fr>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Marek Vasut <marek.vasut@...il.com>,
        David Woodhouse <dwmw2@...radead.org>,
        Brian Norris <computersforpeace@...il.com>,
        Boris Brezillon <boris.brezillon@...e-electrons.com>,
        Richard Weinberger <richard@....at>,
        Joel Stanley <joel@....id.au>,
        Cédric Le Goater <clg@...d.org>,
        Ludovic Barre <ludovic.barre@...com>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        linux-mtd <linux-mtd@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Nicolas Ferre <nicolas.ferre@...rochip.com>
Subject: Re: [PATCH] [RFC] mtd: atmel-quadspi: fix build issues

Hi Arnd,

Le 16/10/2017 à 13:53, Arnd Bergmann a écrit :
> On Fri, Oct 13, 2017 at 10:28 PM, Cyrille Pitchen
> <cyrille.pitchen@...ev4u.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@...ev4u.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?

If it fixes the issue then I'm fine with this proposal.

Best regards,

Cyrille
> 
>        Arnd
>