kernel.git/drivers/of/fdt.c, branch linux-4.9.y

fdt: Update CRC check for rng-seed

2022-07-02T14:17:16Z

commit dd753d961c4844a39f947be115b3d81e10376ee5 upstream. Commit 428826f5358c ("fdt: add support for rng-seed") moves of_fdt_crc32 from early_init_dt_verify() to early_init_dt_scan() since early_init_dt_scan_chosen() may modify fdt to erase rng-seed. However, arm and some other arch won't call early_init_dt_scan(), they call early_init_dt_verify() then early_init_dt_scan_nodes(). Restore of_fdt_crc32 to early_init_dt_verify() then update it in early_init_dt_scan_chosen() if fdt if updated. Fixes: 428826f5358c ("fdt: add support for rng-seed") Reported-by: Geert Uytterhoeven Signed-off-by: Hsin-Yi Wang Tested-by: Geert Uytterhoeven Signed-off-by: Will Deacon Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman

fdt: add support for rng-seed

2022-06-25T09:45:01Z

commit 428826f5358c922dc378830a1717b682c0823160 upstream. Introducing a chosen node, rng-seed, which is an entropy that can be passed to kernel called very early to increase initial device randomness. Bootloader should provide this entropy and the value is read from /chosen/rng-seed in DT. Obtain of_fdt_crc32 for CRC check after early_init_dt_scan_nodes(), since early_init_dt_scan_chosen() would modify fdt to erase rng-seed. Add a new interface add_bootloader_randomness() for rng-seed use case. Depends on whether the seed is trustworthy, rng seed would be passed to add_hwgenerator_randomness(). Otherwise it would be passed to add_device_randomness(). Decision is controlled by kernel config RANDOM_TRUST_BOOTLOADER. Signed-off-by: Hsin-Yi Wang Reviewed-by: Stephen Boyd Reviewed-by: Rob Herring Reviewed-by: Theodore Ts'o # drivers/char/random.c Signed-off-by: Will Deacon Signed-off-by: Jason A. Donenfeld Signed-off-by: Greg Kroah-Hartman

of: Fix truncation of memory sizes on 32-bit platforms

2021-07-20T14:21:05Z

[ Upstream commit 2892d8a00d23d511a0591ac4b2ff3f050ae1f004 ] Variable "size" has type "phys_addr_t", which can be either 32-bit or 64-bit on 32-bit systems, while "unsigned long" is always 32-bit on 32-bit systems. Hence the cast in (unsigned long)size / SZ_1M may truncate a 64-bit size to 32-bit, as casts have a higher operator precedence than divisions. Fix this by inverting the order of the cast and division, which should be safe for memory blocks smaller than 4 PiB. Note that the division is actually a shift, as SZ_1M is a power-of-two constant, hence there is no need to use div_u64(). While at it, use "%lu" to format "unsigned long". Fixes: e8d9d1f5485b52ec ("drivers: of: add initialization code for static reserved memory") Fixes: 3f0c8206644836e4 ("drivers: of: add initialization code for dynamic reserved memory") Signed-off-by: Geert Uytterhoeven Acked-by: Marek Szyprowski Link: https://lore.kernel.org/r/4a1117e72d13d26126f57be034c20dac02f1e915.1623835273.git.geert+renesas@glider.be Signed-off-by: Rob Herring Signed-off-by: Sasha Levin

Revert "fdt: Properly handle "no-map" field in the memory region"

2021-05-22T08:40:29Z

This reverts commit 86ac82a7c708acf4738c396228be7b8fdaae4d99. It is not really a fix, and the backport misses dependencies, which breaks existing platforms. Reported-by: Alexandre TORGUE Signed-off-by: Quentin Perret Signed-off-by: Greg Kroah-Hartman

Revert "of/fdt: Make sure no-map does not remove already reserved regions"

2021-05-22T08:40:28Z

This reverts commit 666ae7c255f9eb7a8fd8e55641542f3624a78b43. It is not really a fix, and the backport misses dependencies, which breaks existing platforms. Reported-by: Alexandre TORGUE Signed-off-by: Quentin Perret Signed-off-by: Greg Kroah-Hartman

of/fdt: Make sure no-map does not remove already reserved regions

2021-03-03T16:44:37Z

[ Upstream commit 8a5a75e5e9e55de1cef5d83ca3589cb4899193ef ] If the device tree is incorrectly configured, and attempts to define a "no-map" reserved memory that overlaps with the kernel data/code, the kernel would crash quickly after boot, with no obvious clue about the nature of the issue. For example, this would happen if we have the kernel mapped at these addresses (from /proc/iomem): 40000000-41ffffff : System RAM 40080000-40dfffff : Kernel code 40e00000-411fffff : reserved 41200000-413e0fff : Kernel data And we declare a no-map shared-dma-pool region at a fixed address within that range: mem_reserved: mem_region { compatible = "shared-dma-pool"; reg = <0 0x40000000 0 0x01A00000>; no-map; }; To fix this, when removing memory regions at early boot (which is what "no-map" regions do), we need to make sure that the memory is not already reserved. If we do, __reserved_mem_reserve_reg will throw an error: [ 0.000000] OF: fdt: Reserved memory: failed to reserve memory for node 'mem_region': base 0x0000000040000000, size 26 MiB and the code that will try to use the region should also fail, later on. We do not do anything for non-"no-map" regions, as memblock explicitly allows reserved regions to overlap, and the commit that this fixes removed the check for that precise reason. [ qperret: fixed conflicts caused by the usage of memblock_mark_nomap ] Fixes: 094cb98179f19b7 ("of/fdt: memblock_reserve /memreserve/ regions in the case of partial overlap") Signed-off-by: Nicolas Boichat Reviewed-by: Stephen Boyd Signed-off-by: Quentin Perret Link: https://lore.kernel.org/r/20210115114544.1830068-3-qperret@google.com Signed-off-by: Rob Herring Signed-off-by: Sasha Levin

fdt: Properly handle "no-map" field in the memory region

2021-03-03T16:44:37Z

[ Upstream commit 86588296acbfb1591e92ba60221e95677ecadb43 ] Mark the memory region with NOMAP flag instead of completely removing it from the memory blocks. That makes the FDT handling consistent with the EFI memory map handling. Cc: Rob Herring Cc: Frank Rowand Cc: devicetree@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: KarimAllah Ahmed Signed-off-by: Quentin Perret Link: https://lore.kernel.org/r/20210115114544.1830068-2-qperret@google.com Signed-off-by: Rob Herring Signed-off-by: Sasha Levin

earlycon: Use a pointer table to fix __earlycon_table stride

2018-05-01T22:13:09Z

commit dd709e72cb934eefd44de8d9969097173fbf45dc upstream. Commit 99492c39f39f ("earlycon: Fix __earlycon_table stride") tried to fix __earlycon_table stride by forcing the earlycon_id struct alignment to 32 and asking the linker to 32-byte align the __earlycon_table symbol. This fix was based on commit 07fca0e57fca92 ("tracing: Properly align linker defined symbols") which tried a similar fix for the tracing subsystem. However, this fix doesn't quite work because there is no guarantee that gcc will place structures packed into an array format. In fact, gcc 4.9 chooses to 64-byte align these structs by inserting additional padding between the entries because it has no clue that they are supposed to be in an array. If we are unlucky, the linker will assign symbol "__earlycon_table" to a 32-byte aligned address which does not correspond to the 64-byte aligned contents of section "__earlycon_table". To address this same problem, the fix to the tracing system was subsequently re-implemented using a more robust table of pointers approach by commits: 3d56e331b653 ("tracing: Replace syscall_meta_data struct array with pointer array") 654986462939 ("tracepoints: Fix section alignment using pointer array") e4a9ea5ee7c8 ("tracing: Replace trace_event struct array with pointer array") Let's use this same "array of pointers to structs" approach for EARLYCON_TABLE. Fixes: 99492c39f39f ("earlycon: Fix __earlycon_table stride") Signed-off-by: Daniel Kurtz Suggested-by: Aaron Durbin Reviewed-by: Rob Herring Tested-by: Guenter Roeck Reviewed-by: Guenter Roeck Cc: stable Signed-off-by: Greg Kroah-Hartman

of: Add check to of_scan_flat_dt() before accessing initial_boot_params

2017-06-29T11:00:31Z

commit 3ec754410cb3e931a6c4920b1a150f21a94a2bf4 upstream. An empty __dtb_start to __dtb_end section might result in initial_boot_params being null for arch/mips/ralink. This showed that the boot process hangs indefinitely in of_scan_flat_dt(). Signed-off-by: Tobias Wolf Cc: Sergei Shtylyov Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14605/ Signed-off-by: Ralf Baechle Signed-off-by: Amit Pundir Signed-off-by: Greg Kroah-Hartman

of: fdt: add missing allocation-failure check

2017-05-25T13:44:37Z

commit 49e67dd17649b60b4d54966e18ec9c80198227f0 upstream. The memory allocator passed to __unflatten_device_tree() (e.g. a wrapped kzalloc) can fail so add the missing sanity check to avoid dereferencing a NULL pointer. Fixes: fe14042358fa ("of/flattree: Refactor unflatten_device_tree and add fdt_unflatten_tree") Signed-off-by: Johan Hovold Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman