Revert of no-map commits 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 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 Signed-off-by: Quentin Perret Signed-off-by: Greg Kroah-Hartman commit 66b8853dfa3cfbbe6c3ab643b6989377ad16662a Author: Quentin Perret 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 Signed-off-by: Quentin Perret Signed-off-by: Greg Kroah-Hartman commit 3cbd3038c9155038020560729cde50588311105d Author: Nicolas Boichat 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 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 commit fb326c6ce0dcbb6273202c6e012759754ec8538d Author: KarimAllah Ahmed 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 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 -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.