Re: [PATCH v3] of/fdt: Don't worry about non-memory region overlap for no-map

[Mike Rapoport <rppt@kernel.org>]

On Wed, Dec 15, 2021 at 11:53:54AM -0800, Stephen Boyd wrote:
> In commit 8a5a75e5e9e5 ("of/fdt: Make sure no-map does not remove
> already reserved regions") we returned -EBUSY when trying to mark
> regions as no-map when they're in the reserved memory node. This if
> condition will still trigger though if the DT has a /memreserve/ that
> completely subsumes the no-map memory carveouts in the reserved memory
> node. Let's only consider this to be a problem if we're trying to mark a
> region as no-map and it is actually memory. If it isn't memory,
> presumably it was removed from the memory map via /memreserve/ and thus
> can't be mapped anyway.

I don't see /memreserve/ removing memory from anywhere. What do you
mean here?

> This silences a warning seen at boot on sc7180-trogdor.dtsi boards that
> have /memreserve/ populated by the bootloader where those reserved
> regions overlap with the reserved-memory carveouts that we have in DT
> for other purposes like communicating with remote processors.
> 
> For example in sc7180.dtsi we have the following reserved-memory
> node:
> 
> 	smem_mem: memory@80900000 {
> 		reg = <0x0 0x80900000 0x0 0x200000>;
> 		no-map;
> 	};
> 
> and the memreserve injected by the bootloader is
> 
> 	/memreserve/ 0x80800000 0x400000;
> 
> so the reserved memory region overlaps with the no-map carveouts and we
> get the following warning message printed at boot:
> 
>  OF: fdt: Reserved memory: failed to reserve memory for node 'memory@80900000': base 0x0000000080900000, size 2 MiB
> 
> Everything keeps working, just the no-map property is being ignored in
> __reserved_mem_reserve_reg() because the region we're trying to avoid
> mapping has already been removed from the memory via the memreserve.
> 
> Cc: Mike Rapoport <rppt@kernel.org>
> Cc: Douglas Anderson <dianders@chromium.org>
> Cc: Nicolas Boichat <drinkcat@chromium.org>
> Cc: Quentin Perret <qperret@google.com>
> Cc: Jan Kiszka <jan.kiszka@siemens.com>
> Fixes: 8a5a75e5e9e5 ("of/fdt: Make sure no-map does not remove already reserved regions")
> Signed-off-by: Stephen Boyd <swboyd@chromium.org>
> ---
> 
> Changes from v2 (https://lore.kernel.org/r/20211215072011.496998-1-swboyd@chromium.org):
>  * More details in commit text
> 
> Changes from v1 (https://lore.kernel.org/r/20210520012731.3731314-1-swboyd@chromium.org):
>  * Use memblock_overlaps_region instead of memblock_is_region_memory()
>  * Add more details to commit text 
> 
>  drivers/of/fdt.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index bdca35284ceb..c736e5bcc2f6 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -482,9 +482,11 @@ static int __init early_init_dt_reserve_memory_arch(phys_addr_t base,
>  	if (nomap) {
>  		/*
>  		 * If the memory is already reserved (by another region), we
> -		 * should not allow it to be marked nomap.
> +		 * should not allow it to be marked nomap, but don't worry
> +		 * if the region isn't memory as it won't be mapped.
>  		 */
> -		if (memblock_is_region_reserved(base, size))
> +		if (memblock_overlaps_region(&memblock.memory, base, size) &&
> +		    memblock_is_region_reserved(base, size))

Apparently I'm missing something, but sc7180.dtsi has memory @80000000 and I
cannot find anything that calls memblock_remove() in DT processing.

How is that memory@80900000 does not overlap with memblock.memory?

>  			return -EBUSY;
>  
>  		return memblock_mark_nomap(base, size);
> 
> base-commit: 136057256686de39cc3a07c2e39ef6bc43003ff6
> -- 
> https://chromeos.dev
> 

-- 
Sincerely yours,
Mike.