linux-kernel - Re: [PATCH v12 4/9] mmc: cavium: Work-around hardware bug on cn6xxx and cnf7xxx

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK8P3a3PBx14CpGY5g7U9YHk3zkvVV=7gJHuSh50eOVKcfVAqA@mail.gmail.com>
Date:   Tue, 21 Mar 2017 20:49:36 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     David Daney <ddaney@...iumnetworks.com>
Cc:     Ulf Hansson <ulf.hansson@...aro.org>,
        Jan Glauber <jglauber@...ium.com>,
        "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Steven J . Hill" <Steven.Hill@...ium.com>,
        David Daney <david.daney@...ium.com>
Subject: Re: [PATCH v12 4/9] mmc: cavium: Work-around hardware bug on cn6xxx
 and cnf7xxx

On Tue, Mar 21, 2017 at 4:19 PM, David Daney <ddaney@...iumnetworks.com> wrote:
> On 03/21/2017 01:58 AM, Arnd Bergmann wrote:
>>
>> On Mon, Mar 20, 2017 at 9:45 PM, David Daney <ddaney@...iumnetworks.com>
>> wrote:
>>>
>>> On 03/17/2017 07:13 AM, Ulf Hansson wrote:
>>>>
>>>> My point is really that we should avoid exporting SoC specific APIs
>>>> which shall be called from drivers. This is old fashion.
>>>
>>>
>>>
>>> Some people find it objectionable to see 1-off architecture specific
>>> in-line
>>> asm in a driver file, but I agree that putting it as close to the user as
>>> possible makes sense.
>>
>>
>> The proper solution might be to create an architecture independent
>> interface
>> for it, what it is that the function does. Can you explain what the
>> purpose
>> of locking/unlocking the cache line for MMC is? Is this something that
>> could be done more generally in the dma_map_ops implementation?
>
>
> It is a 1-off erratum workaround that is only needed on fewer than five
> models/revisions of a mips64 based SoC family.  As such, creating a general
> purpose, architecture independent, framework is clearly not the proper
> approach.

If this is just for maintaining coherency of the DMA operation inbetween,
then there is already a generic API for that, which the driver calls.
Adding the workaround into octeon_dma_map_sg() would be a way
to abstract the platform erratum from the driver.

      Arnd