[PATCH v9 07/11] arm: armv8: mmu: add mmu_unmap_reserved_mem

[Anshul Dalal]

On Fri Oct 10, 2025 at 5:38 PM IST, Ilias Apalodimas wrote:
> Hi Anshul,
>
> On Fri, 10 Oct 2025 at 08:54, Anshul Dalal <anshuld at ti.com> wrote:
>>
>> For armv8, U-Boot uses a static map defined as 'mem_map' for configuring
>> the MMU's page tables, done by mmu_setup.
>>
>> Though this works well for simpler platforms, it makes creating runtime
>> carveouts by modifying the static array at runtime exceedingly complex
>> like in mach-snapdragon/board.c.
>>
>> Creation of such carveouts is much better handled by APIs such as
>> mmu_change_region_attr once the page tables are configured. Usually such
>> carveouts are configured via the device-tree's reserved-memory node
>> which provides the address and size for the carveout.
>>
>> Therefore this patch adds mmu_unmap_reserved_mem which acts as a wrapper
>> over mmu_change_region_attr, helping unmap a reserved-memory region.
>>
>> Signed-off-by: Anshul Dalal <anshuld at ti.com>
>> Tested-by: Wadim Egorov <w.egorov at phytec.de>
>> ---
>>  arch/arm/cpu/armv8/cache_v8.c    | 23 +++++++++++++++++++++++
>>  arch/arm/include/asm/armv8/mmu.h |  9 +++++++++
>>  2 files changed, 32 insertions(+)
>>
>> diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
>> index cdf17d5f396..74814601483 100644
>> --- a/arch/arm/cpu/armv8/cache_v8.c
>> +++ b/arch/arm/cpu/armv8/cache_v8.c
>> @@ -86,6 +86,29 @@ int mem_map_fix_dram_banks(unsigned int index, unsigned int len, u64 attrs)
>>
>>         return 0;
>>  }
>> +
>> +int mmu_unmap_reserved_mem(const char *name)
>> +{
>> +       void *fdt = (void *)gd->fdt_blob;
>> +       char node_path[128];
>> +       fdt_addr_t addr;
>> +       fdt_size_t size;
>> +       int ret;
>> +
>> +       snprintf(node_path, sizeof(node_path), "/reserved-memory/%s", name);
>> +       ret = fdt_path_offset(fdt, node_path);
>> +       if (ret < 0)
>> +               return ret;
>
> The DT spec defines a /reserved/ no-map; option for reserved memory
> that should not participate in the memory map.
> Is there any reason why we unconditionally unmap reserved memory and
> not the no-map one only?
>

I was expecting the caller to only try to unmap regions that already had
no-map but we can add a check here too.

Regards,
Anshul