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 -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
