[PATCH v5 2/6] arch: unify ioremap prototypes and macro aliases

On Wed, Jul 1, 2015 at 1:09 AM, Russell King - ARM Linux
[off-list ref] wrote:

On Wed, Jul 01, 2015 at 08:55:57AM +0200, Geert Uytterhoeven wrote:

quoted

On Wed, Jul 1, 2015 at 8:23 AM, Christoph Hellwig [off-list ref] wrote:

quoted

quoted

One useful feature of the ifdef mess as implemented in the patch is
that you could test for whether ioremap_cache() is actually
implemented or falls back to default ioremap().  I think for
completeness archs should publish an ioremap type capabilities mask
for drivers that care... (I can imagine pmem caring), or default to
being permissive if something like IOREMAP_STRICT is not set.  There's
also the wrinkle of archs that can only support certain types of
mappings at a given alignment.

I think doing this at runtime might be a better idea.  E.g. a
ioremap_flags with the CACHED argument will return -EOPNOTSUP unless
actually implemented.  On various architectures different CPUs or
boards will have different capabilities in this area.

So it would be the responsibility of the caller to fall back from
ioremap(..., CACHED) to ioremap(..., UNCACHED)?
I.e. all drivers using it should be changed...

Another important point here is to define what the properties of the
mappings are.  It's no good just saying "uncached".

We've recently been around this over the PMEM driver and the broken
addition of ioremap_wt() on ARM...

By "properties" I mean stuff like whether unaligned accesses permitted,
any kind of atomic access (eg, xchg, cmpxchg, etc).

This matters: on ARM, a mapping suitable for a device does not support
unaligned accesses or atomic accesses - only "memory-like" mappings
support those.  However, memory-like mappings are not required to
preserve access size, number of accesses, etc which makes them unsuitable
for device registers.

I'm proposing that we explicitly switch "memory-like" use cases over
to a separate set of "memremap()" apis, as these are no longer
"__iomem" [1].

The problem with ioremap_uncached() in particular is that we have LDD
and other documentation telling people to use it to map device registers,
so we can't define ioremap_uncached() on ARM to have memory-like
properties, and it doesn't support unaligned accesses.

I have a series of patches which fix up 32-bit ARM for the broken
ioremap_wt() stuff that was merged during this merge window, which I
intend to push out into linux-next at some point (possibly during the
merge window, if not after -rc1) which also move ioremap*() out of line
on ARM but more importantly, adds a load of documentation about the
properties of the resulting mapping on ARM.

Sounds good, I'll look for that before proceeding on this clean up.

[1]: https://lists.01.org/pipermail/linux-nvdimm/2015-June/001331.html