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.
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
