[PATCH] ARM: stm32mp: Fix dram_bank_mmu_setup() for LMB located above ram_top

[Patrick DELAUNAY]

Hi,

On 12/13/24 14:26, Patrice Chotard wrote:
> Previously, all LMB marked with LMB_NOMAP (above and below ram_top)
> are considered as invalid entry in TLB.
>
> Since commit 1a48b0be93d4 ("lmb: prohibit allocations above ram_top
>   even from same bank") all LMB located above ram_top are now marked
> LMB_NOOVERWRITE and no more LMB_MAP.
>
> This area above ram_top is reserved for OPTEE and must not be cacheable,


minor: OP-TEE


> otherwise this leads to a Panic on some boards (Issue on STM32MP135F-DK).
>
> Restore previous behavior by marking invalid entry all TLB above ram_top.
>
> Fixes: 1a48b0be93d4 ("lmb: prohibit allocations above ram_top even from same bank")
>
> Signed-off-by: Patrice Chotard <patrice.chotard at foss.st.com>
> cc: Sughosh Ganu <sughosh.ganu at linaro.org>
> ---
>
>   arch/arm/mach-stm32mp/stm32mp1/cpu.c | 7 ++++++-
>   1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-stm32mp/stm32mp1/cpu.c b/arch/arm/mach-stm32mp/stm32mp1/cpu.c
> index 62cc98910a7..cb1b84c9af9 100644
> --- a/arch/arm/mach-stm32mp/stm32mp1/cpu.c
> +++ b/arch/arm/mach-stm32mp/stm32mp1/cpu.c
> @@ -53,6 +53,7 @@ void dram_bank_mmu_setup(int bank)
>   	struct bd_info *bd = gd->bd;
>   	int	i;
>   	phys_addr_t start;
> +	phys_addr_t addr;
>   	phys_size_t size;
>   	bool use_lmb = false;
>   	enum dcache_option option;
> @@ -77,8 +78,12 @@ void dram_bank_mmu_setup(int bank)
>   	for (i = start >> MMU_SECTION_SHIFT;
>   	     i < (start >> MMU_SECTION_SHIFT) + (size >> MMU_SECTION_SHIFT);
>   	     i++) {
> +		addr = i << MMU_SECTION_SHIFT;
>   		option = DCACHE_DEFAULT_OPTION;
> -		if (use_lmb && lmb_is_reserved_flags(i << MMU_SECTION_SHIFT, LMB_NOMAP))
> +		if (use_lmb &&
> +		    (lmb_is_reserved_flags(i << MMU_SECTION_SHIFT, LMB_NOMAP) ||
> +		    addr >= gd->ram_top)
> +		   )
>   			option = 0; /* INVALID ENTRY in TLB */
>   		set_section_dcache(i, option);
>   	}


Reviewed-by: Patrick Delaunay <patrick.delaunay at foss.st.com>

Thanks
Patrick