aboutsummaryrefslogtreecommitdiff
path: root/Documentation
diff options
context:
space:
mode:
authorGravatar Andreas Rammhold <andreas@rammhold.de> 2022-12-23 12:27:47 +0100
committerGravatar Rob Herring <robh@kernel.org> 2023-01-03 18:41:01 -0600
commit2a12187d5853d9fd5102278cecef7dac7c8ce7ea (patch)
tree2da31c96a1a9a955b6fb20740c719552e1718480 /Documentation
parentLinux 6.2-rc1 (diff)
downloadlinux-2a12187d5853d9fd5102278cecef7dac7c8ce7ea.tar.gz
linux-2a12187d5853d9fd5102278cecef7dac7c8ce7ea.tar.bz2
linux-2a12187d5853d9fd5102278cecef7dac7c8ce7ea.zip
of/fdt: run soc memory setup when early_init_dt_scan_memory fails
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>
Diffstat (limited to 'Documentation')
0 files changed, 0 insertions, 0 deletions