diff options
| author | Andreas Rammhold <[email protected]> | 2022-12-23 11:27:47 +0000 |
|---|---|---|
| committer | Rob Herring <[email protected]> | 2023-01-04 00:41:01 +0000 |
| commit | 2a12187d5853d9fd5102278cecef7dac7c8ce7ea (patch) | |
| tree | 2da31c96a1a9a955b6fb20740c719552e1718480 /tools/perf/scripts/python/failed-syscalls-by-pid.py | |
| parent | Linux 6.2-rc1 (diff) | |
| download | kernel-2a12187d5853d9fd5102278cecef7dac7c8ce7ea.tar.gz kernel-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: [email protected]
Signed-off-by: Andreas Rammhold <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Rob Herring <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python/failed-syscalls-by-pid.py')
0 files changed, 0 insertions, 0 deletions
