[RFC/PATCH] map drivers. DCACHE option for physmap and mphysmap drivers

[Jared Hulbert]

> > Is this a read-only caching?  I know several architectures and
> > hardware configurations that would quickly throw a machine check if
> > trying to flush the cache back to flash since they don't support
> > bursted writes.
> >
> In general case not.  I've never heard about the such issue. Is there
> any way to define has platform flash devices with bursted writes or not?
> What architectures have this problem?

When I first did a patch like this I used a very platform dependent
embedded assembly loop to _invalidate_ NOT _flush_ the specific
cachelines possibly affected by the flash program or erase. 
consistent_sync() is a great arm specific option to do this but then
ioremap_cached() is very arm specific too.  Invalidating on the arm
arch marks a cacheline as invalid but doesn't try to write it back
while a flush typically refers to a writeback followed by an
invalidate.

 In this case the point is the flash was changed by a program or erase
that  does not change the state of possible contents of the cache so
the flash and cache are out of sync.  We don't care what the cache
contents that point to the affected regions of cache are, we don't
ever want to read them again, so we mark them as invalid and wait for
those lines to be replaced.

Flushing the caches back _could_ be a very bad thing, it could cause
flash to do many bad things because you would be write arbitrary data
back to the flash bus.  I'm not sure why it would machine check.  If
your processor was configured properly I'm not sure why flushing would
trigger burst writes to a memory not capable of bursting, but then
hardware can have its mysterious ways.  Either way you would likely do
bad things to the flash by flushing garbage back to it.  However, from
a higher level look at it you should never be writing directly to the
cached mapping of flash as only the mtd really knows about it and only
uses it read.  Therefore the cachelines are always clean and don't get
written back so it's not really a problem.

However I don't see the value of keeping the commented out lines with
the flushing calls around unless there was a more generic alternative
to ioremap_cached().