Revert of no-map commits

[Tim Ross]

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@xxxxxxxxxx>
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@xxxxxxxxxxx>
    Signed-off-by: Quentin Perret <qperret@xxxxxxxxxx>
    Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>

commit 66b8853dfa3cfbbe6c3ab643b6989377ad16662a
Author: Quentin Perret <qperret@xxxxxxxxxx>
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@xxxxxxxxxxx>
    Signed-off-by: Quentin Perret <qperret@xxxxxxxxxx>
    Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>

commit 3cbd3038c9155038020560729cde50588311105d
Author: Nicolas Boichat <drinkcat@xxxxxxxxxxxx>
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@xxxxxxxxxxxx>
    Reviewed-by: Stephen Boyd <swboyd@xxxxxxxxxxxx>
    Signed-off-by: Quentin Perret <qperret@xxxxxxxxxx>
    Link: https://lore.kernel.org/r/20210115114544.1830068-3-qperret@xxxxxxxxxx
    Signed-off-by: Rob Herring <robh@xxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

commit fb326c6ce0dcbb6273202c6e012759754ec8538d
Author: KarimAllah Ahmed <karahmed@xxxxxxxxx>
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@xxxxxxxxxx>
    Cc: Frank Rowand <frowand.list@xxxxxxxxx>
    Cc: devicetree@xxxxxxxxxxxxxxx
    Cc: linux-kernel@xxxxxxxxxxxxxxx
    Signed-off-by: KarimAllah Ahmed <karahmed@xxxxxxxxx>
    Signed-off-by: Quentin Perret <qperret@xxxxxxxxxx>
    Link: https://lore.kernel.org/r/20210115114544.1830068-2-qperret@xxxxxxxxxx
    Signed-off-by: Rob Herring <robh@xxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

-- 
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.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature