I noticed that the reverts below were made to the 4.9 and 5.4 branches, but I do not see them elsewhere (other stable branches, latest, etc). The original commits which were subsequently reverted on the 4.9 and 5.4 branches were causing our cable-modem drivers memremap calls to fail so we need these reverted everywhere like they are on the 4.9 and 5.4 branches. Is that the plan?

-Tim

ommit 6b183fbf18b91bc3c1fd02d5a48f7bc447d900cedrivers/of/fdt.c Author: Quentin Perret qperret@google.com Date: Wed May 12 12:28:53 2021 +0000

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

This reverts commit fb326c6ce0dcbb6273202c6e012759754ec8538d. It is not really a fix, and the backport misses dependencies, which breaks existing platforms.

Reported-by: Alexandre TORGUE alexandre.torgue@foss.st.com Signed-off-by: Quentin Perret qperret@google.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org

commit 66b8853dfa3cfbbe6c3ab643b6989377ad16662a Author: Quentin Perret qperret@google.com Date: Wed May 12 12:28:52 2021 +0000

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

This reverts commit 3cbd3038c9155038020560729cde50588311105d. It is not really a fix, and the backport misses dependencies, which breaks existing platforms.

Reported-by: Alexandre TORGUE alexandre.torgue@foss.st.com Signed-off-by: Quentin Perret qperret@google.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org

commit 3cbd3038c9155038020560729cde50588311105d Author: Nicolas Boichat drinkcat@chromium.org Date: Fri Jan 15 11:45:44 2021 +0000

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

[ 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 drinkcat@chromium.org Reviewed-by: Stephen Boyd swboyd@chromium.org Signed-off-by: Quentin Perret qperret@google.com Link: https://lore.kernel.org/r/20210115114544.1830068-3-qperret@google.com Signed-off-by: Rob Herring robh@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org

commit fb326c6ce0dcbb6273202c6e012759754ec8538d Author: KarimAllah Ahmed karahmed@amazon.de Date: Fri Jan 15 11:45:43 2021 +0000

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

[ 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 robh+dt@kernel.org Cc: Frank Rowand frowand.list@gmail.com Cc: devicetree@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: KarimAllah Ahmed karahmed@amazon.de Signed-off-by: Quentin Perret qperret@google.com Link: https://lore.kernel.org/r/20210115114544.1830068-2-qperret@google.com Signed-off-by: Rob Herring robh@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org