Hi Serge,
On 19.12.2016 03:07, Serge Semin wrote:
Bootmem allocator initialization needs to be discarded.
PFN limit constants are still in use by some subsystems, so they
need to be properly initialized. The initialization is moved into
a separate method and performed with help of commonly used
platform-specific constants. It might me too simplified, but most
of the kernel platforms do it the same way. Moreover it's much
easier to debug it, when it's not that complicated.
Signed-off-by: Serge Semin <fancer.lancer@xxxxxxxxx>
---
arch/mips/kernel/setup.c | 193 ++++-------------------------
1 file changed, 21 insertions(+), 172 deletions(-)
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index e746793..6562f55 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -626,6 +626,25 @@ static void __init request_crashkernel(struct resource *res) { }
#endif /* !CONFIG_KEXEC */
/*
+ * Calcualte PFN limits with respect to the defined memory layout
+ */
+static void __init find_pfn_limits(void)
+{
+ phys_addr_t ram_end = memblock_end_of_DRAM();
+
+ min_low_pfn = ARCH_PFN_OFFSET;
+ max_low_pfn = PFN_UP(HIGHMEM_START);
This doesn't look right - as this may set max_low_pfn to more than the
actual physical memory size. In some cases this might be a serious
problem and it doesn't look like any other platform does that.
Even in MIPS code you can find uses of max_low_pfn that would be
seriously affected by this change (vpe loader with
CONFIG_MIPS_VPE_LOADER_TOM).
+ max_pfn = PFN_UP(ram_end);
+#ifdef CONFIG_HIGHMEM
+ highstart_pfn = max_low_pfn;
+ highend_pfn = max_pfn <= highstart_pfn ? highstart_pfn : max_pfn;
+#endif
+ pr_info("PFNs: low min %lu, low max %lu, high start %lu, high end %lu,"
+ "max %lu\n",
+ min_low_pfn, max_low_pfn, highstart_pfn, highend_pfn, max_pfn);
+}
+
+/*
* Initialize the bootmem allocator. It also setup initrd related data
* if needed.
*/
I fully agree with you that the current initialisation code is really
complex and difficult to debug, but the modified one seems a bit too
simplified.
Regards,
Marcin
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
