diff mbox series

of/fdt: run soc memory setup when early_init_dt_scan_memory fails

Message ID 20221223112748.2935235-1-andreas@rammhold.de (mailing list archive)
State Handled Elsewhere
Headers show
Series of/fdt: run soc memory setup when early_init_dt_scan_memory fails | expand

Commit Message

Andreas Rammhold Dec. 23, 2022, 11:27 a.m. UTC
From: Andreas Rammhold <andreas@rammhold.de>

If memory has been found early_init_dt_scan_memory now returns 1. If
it hasn't found any memory it will return 0, allowing other memory
setup mechanisms to carry on.

Previously early_init_dt_scan_memory always returned 0 without
distinguishing between any kind of memory setup being done or not. Any
code path after the early_init_dt_scan memory call in the ramips
plat_mem_setup code wouldn't be executed anymore. Making
early_init_dt_scan_memory the only way to initialize the memory.

Some boards, including my mt7621 based Cudy X6 board, depend on memory
initialization being done via the soc_info.mem_detect function
pointer. Those wouldn't be able to obtain memory and panic the kernel
during early bootup with the message "early_init_dt_alloc_memory_arch:
Failed to allocate 12416 bytes align=0x40".

Fixes: 1f012283e936 ("of/fdt: Rework early_init_dt_scan_memory() to call directly")
Cc: stable@vger.kernel.org
Signed-off-by: Andreas Rammhold <andreas@rammhold.de>
---
 arch/mips/ralink/of.c | 2 +-
 drivers/of/fdt.c      | 6 ++++--
 2 files changed, 5 insertions(+), 3 deletions(-)

Comments

Rob Herring Jan. 4, 2023, 12:41 a.m. UTC | #1
On Fri, 23 Dec 2022 12:27:47 +0100, andreas@rammhold.de wrote:
> From: Andreas Rammhold <andreas@rammhold.de>
> 
> If memory has been found early_init_dt_scan_memory now returns 1. If
> it hasn't found any memory it will return 0, allowing other memory
> setup mechanisms to carry on.
> 
> Previously early_init_dt_scan_memory always returned 0 without
> distinguishing between any kind of memory setup being done or not. Any
> code path after the early_init_dt_scan memory call in the ramips
> plat_mem_setup code wouldn't be executed anymore. Making
> early_init_dt_scan_memory the only way to initialize the memory.
> 
> Some boards, including my mt7621 based Cudy X6 board, depend on memory
> initialization being done via the soc_info.mem_detect function
> pointer. Those wouldn't be able to obtain memory and panic the kernel
> during early bootup with the message "early_init_dt_alloc_memory_arch:
> Failed to allocate 12416 bytes align=0x40".
> 
> Fixes: 1f012283e936 ("of/fdt: Rework early_init_dt_scan_memory() to call directly")
> Cc: stable@vger.kernel.org
> Signed-off-by: Andreas Rammhold <andreas@rammhold.de>
> ---
>  arch/mips/ralink/of.c | 2 +-
>  drivers/of/fdt.c      | 6 ++++--
>  2 files changed, 5 insertions(+), 3 deletions(-)
> 

Applied, thanks!
diff mbox series

Patch

diff --git a/arch/mips/ralink/of.c b/arch/mips/ralink/of.c
index ea8072acf8d94..6873b02634219 100644
--- a/arch/mips/ralink/of.c
+++ b/arch/mips/ralink/of.c
@@ -63,7 +63,7 @@  void __init plat_mem_setup(void)
 	dtb = get_fdt();
 	__dt_setup_arch(dtb);
 
-	if (!early_init_dt_scan_memory())
+	if (early_init_dt_scan_memory())
 		return;
 
 	if (soc_info.mem_detect)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 7b571a6316397..4f88e8bbdd279 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -1099,7 +1099,7 @@  u64 __init dt_mem_next_cell(int s, const __be32 **cellp)
  */
 int __init early_init_dt_scan_memory(void)
 {
-	int node;
+	int node, found_memory = 0;
 	const void *fdt = initial_boot_params;
 
 	fdt_for_each_subnode(node, fdt, 0) {
@@ -1139,6 +1139,8 @@  int __init early_init_dt_scan_memory(void)
 
 			early_init_dt_add_memory_arch(base, size);
 
+			found_memory = 1;
+
 			if (!hotpluggable)
 				continue;
 
@@ -1147,7 +1149,7 @@  int __init early_init_dt_scan_memory(void)
 					base, base + size);
 		}
 	}
-	return 0;
+	return found_memory;
 }
 
 int __init early_init_dt_scan_chosen(char *cmdline)