kernel/linux.git/drivers/of/fdt.c, branch v6.12.80

arm64: kdump: Fix elfcorehdr overlap caused by reserved memory processing reorder

2026-01-08T09:14:05+00:00

[ Upstream commit 3e8ade58b71b48913d21b647b2089e03e81f117e ] Commit 8a6e02d0c00e ("of: reserved_mem: Restructure how the reserved memory regions are processed") changed the processing order of reserved memory regions, causing elfcorehdr to overlap with dynamically allocated reserved memory regions during kdump kernel boot. The issue occurs because: 1. kexec-tools allocates elfcorehdr in the last crashkernel reserved memory region and passes it to the second kernel 2. The problematic commit moved dynamic reserved memory allocation (like bman-fbpr) to occur during fdt_scan_reserved_mem(), before elfcorehdr reservation in fdt_reserve_elfcorehdr() 3. bman-fbpr with 16MB alignment requirement can get allocated at addresses that overlap with the elfcorehdr location 4. When fdt_reserve_elfcorehdr() tries to reserve elfcorehdr memory, overlap detection identifies the conflict and skips reservation 5. kdump kernel fails with "Unable to handle kernel paging request" because elfcorehdr memory is not properly reserved The boot log: Before 8a6e02d0c00e: OF: fdt: Reserving 1 KiB of memory at 0xf4fff000 for elfcorehdr OF: reserved mem: 0xf3000000..0xf3ffffff bman-fbpr After 8a6e02d0c00e: OF: reserved mem: 0xf4000000..0xf4ffffff bman-fbpr OF: fdt: elfcorehdr is overlapped Fix this by ensuring elfcorehdr reservation occurs before dynamic reserved memory allocation. Fixes: 8a6e02d0c00e ("of: reserved_mem: Restructure how the reserved memory regions are processed") Signed-off-by: Jianpeng Chang Link: https://patch.msgid.link/20251205015934.700016-1-jianpeng.chang.cn@windriver.com Signed-off-by: Rob Herring (Arm) Signed-off-by: Sasha Levin

of/fdt: Restore possibility to use both ACPI and FDT from bootloader

2025-02-08T08:57:52+00:00

[ Upstream commit 14bce187d1600710623d81888da3501bbc470ba2 ] There are cases when the bootloader provides information to the kernel in both ACPI and DTB, not interchangeably. One such use case is virtual machines in Android. When running on x86, the Android Virtualization Framework (AVF) boots VMs with ACPI like it is usually done on x86 (i.e. the virtual LAPIC, IOAPIC, HPET, PCI MMCONFIG etc are described in ACPI) but also passes various AVF-specific boot parameters in DTB. This allows reusing the same implementations of various AVF components on both arm64 and x86. Commit 7b937cc243e5 ("of: Create of_root if no dtb provided by firmware") removed the possibility to do that, since among other things it introduced forcing emptying the bootloader-provided DTB if ACPI is enabled (probably assuming that if ACPI is available, a DTB can only be useful for applying overlays to it afterwards, for testing purposes). So restore this possibility. Instead of completely preventing using ACPI and DT together, rely on arch-specific setup code to prevent using both to set up the same things (see various acpi_disabled checks under arch/). Fixes: 7b937cc243e5 ("of: Create of_root if no dtb provided by firmware") Signed-off-by: Dmytro Maluka Link: https://lore.kernel.org/r/20250105172741.3476758-3-dmaluka@chromium.org Signed-off-by: Rob Herring (Arm) Signed-off-by: Sasha Levin

of: reserved_mem: Restructure how the reserved memory regions are processed

2025-02-08T08:57:52+00:00

[ Upstream commit 8a6e02d0c00e7b62e6acb74146878bb91e9e7e31 ] Reserved memory regions defined in the devicetree can be broken up into two groups: i) Statically-placed reserved memory regions i.e. regions defined with a static start address and size using the "reg" property. ii) Dynamically-placed reserved memory regions. i.e. regions defined by specifying an address range where they can be placed in memory using the "alloc_ranges" and "size" properties. These regions are processed and set aside at boot time. This is done in two stages as seen below: Stage 1: At this stage, fdt_scan_reserved_mem() scans through the child nodes of the reserved_memory node using the flattened devicetree and does the following: 1) If the node represents a statically-placed reserved memory region, i.e. if it is defined using the "reg" property: - Call memblock_reserve() or memblock_mark_nomap() as needed. - Add the information for that region into the reserved_mem array using fdt_reserved_mem_save_node(). i.e. fdt_reserved_mem_save_node(node, name, base, size). 2) If the node represents a dynamically-placed reserved memory region, i.e. if it is defined using "alloc-ranges" and "size" properties: - Add the information for that region to the reserved_mem array with the starting address and size set to 0. i.e. fdt_reserved_mem_save_node(node, name, 0, 0). Note: This region is saved to the array with a starting address of 0 because a starting address is not yet allocated for it. Stage 2: After iterating through all the reserved memory nodes and storing their relevant information in the reserved_mem array,fdt_init_reserved_mem() is called and does the following: 1) For statically-placed reserved memory regions: - Call the region specific init function using __reserved_mem_init_node(). 2) For dynamically-placed reserved memory regions: - Call __reserved_mem_alloc_size() which is used to allocate memory for each of these regions, and mark them as nomap if they have the nomap property specified in the DT. - Call the region specific init function. The current size of the resvered_mem array is 64 as is defined by MAX_RESERVED_REGIONS. This means that there is a limitation of 64 for how many reserved memory regions can be specified on a system. As systems continue to grow more and more complex, the number of reserved memory regions needed are also growing and are starting to hit this 64 count limit, hence the need to make the reserved_mem array dynamically sized (i.e. dynamically allocating memory for the reserved_mem array using membock_alloc_*). On architectures such as arm64, memory allocated using memblock is writable only after the page tables have been setup. This means that if the reserved_mem array is going to be dynamically allocated, it needs to happen after the page tables have been setup, not before. Since the reserved memory regions are currently being processed and added to the array before the page tables are setup, there is a need to change the order in which some of the processing is done to allow for the reserved_mem array to be dynamically sized. It is possible to process the statically-placed reserved memory regions without needing to store them in the reserved_mem array until after the page tables have been setup because all the information stored in the array is readily available in the devicetree and can be referenced at any time. Dynamically-placed reserved memory regions on the other hand get assigned a start address only at runtime, and hence need a place to be stored once they are allocated since there is no other referrence to the start address for these regions. Hence this patch changes the processing order of the reserved memory regions in the following ways: Step 1: fdt_scan_reserved_mem() scans through the child nodes of the reserved_memory node using the flattened devicetree and does the following: 1) If the node represents a statically-placed reserved memory region, i.e. if it is defined using the "reg" property: - Call memblock_reserve() or memblock_mark_nomap() as needed. 2) If the node represents a dynamically-placed reserved memory region, i.e. if it is defined using "alloc-ranges" and "size" properties: - Call __reserved_mem_alloc_size() which will: i) Allocate memory for the reserved region and call memblock_mark_nomap() as needed. ii) Call the region specific initialization function using fdt_init_reserved_mem_node(). iii) Save the region information in the reserved_mem array using fdt_reserved_mem_save_node(). Step 2: 1) This stage of the reserved memory processing is now only used to add the statically-placed reserved memory regions into the reserved_mem array using fdt_scan_reserved_mem_reg_nodes(), as well as call their region specific initialization functions. 2) This step has also been moved to be after the page tables are setup. Moving this will allow us to replace the reserved_mem array with a dynamically sized array before storing the rest of these regions. Signed-off-by: Oreoluwa Babatunde Link: https://lore.kernel.org/r/20241008220624.551309-2-quic_obabatun@quicinc.com Signed-off-by: Rob Herring (Arm) Stable-dep-of: 14bce187d160 ("of/fdt: Restore possibility to use both ACPI and FDT from bootloader") Signed-off-by: Sasha Levin

of/fdt: add dt_phys arg to early_init_dt_scan and early_init_dt_verify

2024-12-05T13:01:32+00:00

[ Upstream commit b2473a359763e27567993e7d8f37de82f57a0829 ] __pa() is only intended to be used for linear map addresses and using it for initial_boot_params which is in fixmap for arm64 will give an incorrect value. Hence save the physical address when it is known at boot time when calling early_init_dt_scan for arm64 and use it at kexec time instead of converting the virtual address using __pa(). Note that arm64 doesn't need the FDT region reserved in the DT as the kernel explicitly reserves the passed in FDT. Therefore, only a debug warning is fixed with this change. Reported-by: Breno Leitao Suggested-by: Mark Rutland Signed-off-by: Usama Arif Fixes: ac10be5cdbfa ("arm64: Use common of_kexec_alloc_and_setup_fdt()") Link: https://lore.kernel.org/r/20241023171426.452688-1-usamaarif642@gmail.com Signed-off-by: Rob Herring (Arm) Signed-off-by: Sasha Levin

kbuild: split device tree build rules into scripts/Makefile.dtbs

2024-09-09T14:42:13+00:00

scripts/Makefile.lib is included not only from scripts/Makefile.build but also from scripts/Makefile.{modfinal,package,vmlinux,vmlinux_o}, where DT build rules are not required. Split the DT build rules out to scripts/Makefile.dtbs, and include it only when necessary. While I was here, I added $(DT_TMP_SCHEMA) as a prerequisite of $(multi-dtb-y). Signed-off-by: Masahiro Yamada Reviewed-by: Rob Herring (Arm)

of/fdt: avoid re-parsing '#{address,size}-cells' in of_fdt_limit_memory

2024-05-31T13:33:54+00:00

Now that we initialize dt_root_addr_cells and dt_root_size_cells earlier, use them and simplify of_fdt_limit_memory. Link: https://lore.kernel.org/all/20180830190523.31474-3-robh@kernel.org/ Signed-off-by: Rob Herring

of/fdt: Scan the root node properties earlier

2024-05-31T13:33:54+00:00

Scan the root node properties (#{size,address}-cells) earlier, so that the dt_root_addr_cells and dt_root_size_cells variables are initialized and can be used. Link: https://lore.kernel.org/all/20180830190523.31474-2-robh@kernel.org/ Signed-off-by: Rob Herring

of: Move all FDT reserved-memory handling into of_reserved_mem.c

2024-03-12T15:23:26+00:00

The split of /reserved-memory handling between fdt.c and of_reserved_mem.c makes for reading and restructuring the code difficult. As of_reserved_mem.c is only built for CONFIG_OF_EARLY_FLATTREE already, move all the code to one spot. Acked-by: Saravana Kannan Reviewed-by: Oreoluwa Babatunde Link: https://lore.kernel.org/r/20240311181303.1516514-2-robh@kernel.org Signed-off-by: Rob Herring

of: Create of_root if no dtb provided by firmware

2024-03-08T18:50:39+00:00

When enabling CONFIG_OF on a platform where 'of_root' is not populated by firmware, we end up without a root node. In order to apply overlays and create subnodes of the root node, we need one. Create this root node by unflattening an empty builtin dtb. If firmware provides a flattened device tree (FDT) then the FDT is unflattened via setup_arch(). Otherwise, the call to unflatten(_and_copy)?_device_tree() will create an empty root node. We make of_have_populated_dt() return true only if the DTB was loaded by firmware so that existing callers don't change behavior after this patch. The call in the of platform code is removed because it prevents overlays from creating platform devices when the empty root node is used. [sboyd@kernel.org: Update of_have_populated_dt() to treat this empty dtb as not populated. Drop setup_of() initcall] Signed-off-by: Frank Rowand Link: https://lore.kernel.org/r/20230317053415.2254616-2-frowand.list@gmail.com Cc: Rob Herring Signed-off-by: Stephen Boyd Link: https://lore.kernel.org/r/20240217010557.2381548-3-sboyd@kernel.org Signed-off-by: Rob Herring

of: Always unflatten in unflatten_and_copy_device_tree()

2024-03-08T18:50:39+00:00

We want to populate an empty DT whenever CONFIG_OF is enabled so that overlays can be applied and the DT unit tests can be run. Make unflatten_and_copy_device_tree() stop printing a warning if the 'initial_boot_params' pointer is NULL. Instead, simply copy the dtb if there is one and then unflatten it. If there isn't a DT to copy, then the call to unflatten_device_tree() is largely a no-op, so nothing really changes here. Cc: Rob Herring Cc: Frank Rowand Signed-off-by: Stephen Boyd Link: https://lore.kernel.org/r/20240217010557.2381548-2-sboyd@kernel.org Signed-off-by: Rob Herring