On 23 February 2016 at 12:58, Russell King - ARM Linux
[off-list ref] wrote:

On Mon, Feb 22, 2016 at 09:35:24PM +0100, Ard Biesheuvel wrote:

quoted

OK, thanks for the historical context.

So what is your opinion on this series, i.e., to wire up memremap() to
remap arbitrary memory regions into the vmalloc area with MT_MEMORY_RW
attributes, and at the same time lift the restriction that the region
must be disjoint from memory covered by lowmem or kmap?

The historical context is still present, because pxa2xx-flash has
been converted to use memremap() from ioremap_cache() - possibly
inappropriately.

I've already described the semantics of ioremap_cache(), which are
to always create a cacheable mapping irrespective of the system
memory mapping type.  However, memremap() says that MEMREMAP_WB
matches system RAM, which on ARM it doesn't right now.

Indeed. Hence this series, to decouple memremap(MEMREMAP_WB) from
ioremap_cache() for ARM

Changing it to MT_MEMORY_RW would satisfy that comment against
memremap(), but at the same time changes what happens with
pxa2xx-flash - the memory region (which is not system RAM) then
changes with the cache status of system RAM.

So, I'm not that happy about the memremap() stuff right now, and
I don't like the idea of making memremap() conform to its stated
requirements without first preventing pxa2xx-flash being affected
by such a change.

Actually, my change fixes this issue, since it will cause memremap()
to always create MT_MEMORY_RW mappings, and not fallback to
ioremap_cache() for ranges that are not covered by lowmem.

Perhaps we need to reinstate the original ioremap_cached() API for
pxa2xx-flash, and then switch memremap() to MT_MEMORY_RW - that
would seem to result in the expected behaviour by all parties.

I think we can simply revert the change to pxa2xx-flash if it is
deemed inappropriate.