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: <20170322100008.GA2869@hardcore>
Date:   Wed, 22 Mar 2017 11:00:08 +0100
From:   Jan Glauber <jan.glauber@...iumnetworks.com>
To:     David Daney <ddaney@...iumnetworks.com>
Cc:     Arnd Bergmann <arnd@...db.de>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        "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 01:22:05PM -0700, David Daney wrote:
> On 03/21/2017 12:49 PM, Arnd Bergmann wrote:
> >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.
> >
> 
> Either I am bad at explaining things, or you are not reading what I wrote.
> 
> These are two facts about the bug:
> 
> 1) The bug has nothing to do with coherency management, so hacking
> something into dma_map* is the wrong thing to do.
> 
> 2) The bug effects exactly one device, so hacking something into
> common code that is used by other devices is the wrong thing to do.
> 
> Suggesting that we use an alternate set of facts, although an
> interesting exercise, doesn't get us closer to answering the
> question of which source code file should contain the code.
> 
> This is one opinion about the bug:
> 
> 1) The bug is in the device, not the "platform", so putting the
> workaround code in the driver for the device may be the cleanest
> approach.

I've moved the code into the octeon driver
(drivers/mmc/host/cavium-octeon.c) and think this is the cleanest
way to do it.

--Jan

> David Daney