Linuxメモ（跡地）

void __iomem * __arm_ioremap_pfn_caller(unsigned long pfn,
/*
 * Don't allow RAM to be mapped - this causes problems with ARMv6+
 */
if (WARN_ON(pfn_valid(pfn)))
        return NULL;

linux kernelコミットログを漁る

commit 576d2f2525612ecb5af029a76f21f22a3b82563d
Author: Nicolas Pitre <nicolas.pitre@linaro.org>
Date:   Fri Sep 16 01:14:23 2011 -0400

    ARM: add generic ioremap optimization by reusing static mappings
    
    Now that we have all the static mappings from iotable_init() located
    in the vmalloc area, it is trivial to optimize ioremap by reusing those
    static mappings when the requested physical area fits in one of them,
    and so in a generic way for all platforms.
    
    Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
    Tested-by: Stephen Warren <swarren@nvidia.com>
    Tested-by: Kevin Hilman <khilman@ti.com>
    Tested-by: Jamie Iles <jamie@jamieiles.com>

commit 309caa9cc6ff39d261264ec4ff10e29489afc8f8
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Mon Jun 21 21:03:18 2010 +0100

    ARM: Prohibit ioremap() on kernel managed RAM
    
    ARMv6 and above have a restriction whereby aliasing virtual:physical
    mappings must not have differing memory type and sharability
    attributes.  Strictly, this covers the memory type (strongly ordered,
    device, memory), cache attributes (uncached, write combine, write
    through, write back read alloc, write back write alloc) and the
    shared bit.
    
    However, using ioremap() and its variants on system RAM results in
    mappings which differ in these attributes from the main system RAM
    mapping.  Other architectures which similar restrictions approch this
    problem in the same way - they do not permit ioremap on main system
    RAM.
    
    Make ARM behave in the same way, with a WARN_ON() such that users can
    be traced and an alternative approach found.
    
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

総論