of/fdt: run soc memory setup when early_init_dt_scan_memory fails
authorAndreas Rammhold <andreas@rammhold.de>
Fri, 23 Dec 2022 11:27:47 +0000 (12:27 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 12 Jan 2023 11:02:51 +0000 (12:02 +0100)
commitc4849f18185fd4e93b04cd45552f8d68c0240e21
treedb9590880e44a558890cd87e82334a0ab42c2f2e
parenta33220faead65fd3ac42284f32b83094543ea91b
of/fdt: run soc memory setup when early_init_dt_scan_memory fails

commit 2a12187d5853d9fd5102278cecef7dac7c8ce7ea upstream.

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>
Link: https://lore.kernel.org/r/20221223112748.2935235-1-andreas@rammhold.de
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
arch/mips/ralink/of.c
drivers/of/fdt.c