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
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
27 Jul, 2010
2 commits
-
Signed-off-by: Russell King
-
Acked-by: Tony Lindgren
Signed-off-by: Russell King