13 Jan, 2012

1 commit

  • Several platforms are now using the memblock_alloc+memblock_free+
    memblock_remove trick to obtain memory which won't be mapped in the
    kernel's page tables. Most platforms do this (correctly) in the
    ->reserve callback. However, OMAP has started to call these functions
    outside of this callback, and this is extremely unsafe - memory will
    not be unmapped, and could well be given out after memblock is no
    longer responsible for its management.

    So, provide arm_memblock_steal() to perform this function, and ensure
    that it panic()s if it is used inappropriately. Convert everyone
    over, including OMAP.

    As a result, OMAP with OMAP4_ERRATA_I688 enabled will panic on boot
    with this change. Mark this option as BROKEN and make it depend on
    BROKEN. OMAP needs to be fixed, or 137d105d50 (ARM: OMAP4: Fix
    errata i688 with MPU interconnect barriers.) reverted until such
    time it can be fixed correctly.

    Signed-off-by: Russell King

    Russell King
     

28 Oct, 2010

1 commit

  • Will says:
    | Commit e63075a3 removed the explicit MEMBLOCK_REAL_LIMIT #define
    | and introduced the requirement that arch code calls
    | memblock_set_current_limit to ensure that the __va macro can
    | be used on physical addresses returned from memblock_alloc.

    Unfortunately, ARM was missed out of this change. Fix this.

    Reported-by: Will Deacon
    Signed-off-by: Russell King

    Russell King
     

27 Jul, 2010

2 commits