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

[Jan Glauber]

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@xxxxxxxxxxxxxxxxxx> wrote:
> >>On 03/21/2017 01:58 AM, Arnd Bergmann wrote:
> >>>
> >>>On Mon, Mar 20, 2017 at 9:45 PM, David Daney <ddaney@xxxxxxxxxxxxxxxxxx>
> >>>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