sh doesn't access early_node_map[] directly and enabling HAVE_MEMBLOCK_NODE_MAP is trivial - replacing add_active_range() calls with memblock_set_node() and selecting HAVE_MEMBLOCK_NODE_MAP is enough. Signed-off-by: Tejun Heo <tj@xxxxxxxxxx> Cc: Paul Mundt <lethal@xxxxxxxxxxxx> Cc: linux-sh@xxxxxxxxxxxxxxx --- Paul, memblock now can carry node information itself without relying on early_node_map[], which makes operations which make use of both information much saner and generally makes NUMA memory init simpler. For more details, please read the following thread. http://thread.gmane.org/gmane.linux.kernel.cross-arch/10354 I couldn't get the cross-compiler from korg to build configuration with CPU w/ NUMA support but given the trivial nature of the change, I don't think it would cause build failures on different configs, but this definitely needs testing on actual NUMA configuration. The patches implementing HAVE_MEMBLOCK_NODE_MAP is currently in tip:x86/memblock branch on which this patch is based on. Thanks. arch/sh/Kconfig | 1 + arch/sh/kernel/setup.c | 3 ++- 2 files changed, 3 insertions(+), 1 deletions(-) diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig index bbdeb48..8c10d85 100644 --- a/arch/sh/Kconfig +++ b/arch/sh/Kconfig @@ -4,6 +4,7 @@ config SUPERH select CLKDEV_LOOKUP select HAVE_IDE if HAS_IOPORT select HAVE_MEMBLOCK + select HAVE_MEMBLOCK_NODE_MAP select HAVE_OPROFILE select HAVE_GENERIC_DMA_COHERENT select HAVE_ARCH_TRACEHOOK diff --git a/arch/sh/kernel/setup.c b/arch/sh/kernel/setup.c index 58bff45..e3942ca 100644 --- a/arch/sh/kernel/setup.c +++ b/arch/sh/kernel/setup.c @@ -227,7 +227,8 @@ void __init __add_active_range(unsigned int nid, unsigned long start_pfn, pmb_bolt_mapping((unsigned long)__va(start), start, end - start, PAGE_KERNEL); - add_active_range(nid, start_pfn, end_pfn); + memblock_set_node(PFN_PHYS(start_pfn), + PFN_PHYS(end_pfn - start_pfn), nid); } void __init __weak plat_early_device_setup(void) -- 1.7.6 -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
