Re: [PATCH v3] ARM: set !LPAE MAX_PHYSMEM_BITS to 32 and remove supersection mappings

[Arnd Bergmann]

On Sat, Jul 25, 2026, at 15:31, Karl Mehltretter wrote:
> An ARM randconfig with CONFIG_GET_FREE_REGION=y and CONFIG_WERROR=y
> fails to build:
>
>   include/linux/minmax.h:86:37: error: conversion from 'long long
>   unsigned int' to 'resource_size_t' {aka 'unsigned int'} changes
>   value from '68719476735' to '4294967295' [-Werror=overflow]
>
> Commit 14b80582c43e ("resource: Introduce alloc_free_mem_region()")
> made kernel/resource.c clamp against
> (1ULL << MAX_PHYSMEM_BITS) - 1.  resource_size_t is 32-bit without
> LPAE, but ARM's default MAX_PHYSMEM_BITS is 36.
>
> That default was added by commit db57f88e4ccb ("ARM: 8411/1: Add
> default SPARSEMEM settings") because several platforms needed at
> least 36 physical address bits.  !LPAE could map addresses above
> 32 bits only through supersections.
>
> CONFIG_IO_36, added by commit 23bdf86aa06e ("[ARM] 3377/2: add
> support for intel xsc3 core"), enabled these for XSC3 I/O.  IXP23xx
> placed static I/O mappings above 4GiB until its removal in 2012, and
> IOP13xx ioremap()ed its PCIe windows there until its removal in 2019.
> The only remaining XSC3 platform, PXA3xx, has nothing above 4GiB.
>
> Supersection address bits overlap the descriptor domain field, so
> IO_36 also renumbered the domains to make DOMAIN_IO zero.  Remove
> IO_36, the alternate domain numbering, and ioremap()'s supersection
> path.  Reject !LPAE ioremap ranges extending past 4GiB before
> phys_addr_t truncation, drop the now-unneeded high static-mapping
> exclusion, and reduce ioremap alignment from 16MiB to the 2MiB
> covered by a PMD's pair of sections.
>
> The other supersection user, create_36bit_mapping(), was added by
> commit 0b7cd62ecdc1 ("[ARM] 3017/1: Add support for 36-bit addresses
> to create_mapping()") for IXP2350 and carried IXP23xx's high static
> mappings.  Before this change, its only remaining call path was
> efi_create_mapping() -> create_mapping_late(), for an EFI runtime
> region above 4GiB.
>
> No real-world user of this !LPAE path is known.  AArch32 UEFI
> requires RAM described by its memory map to be identity-mapped
> during boot services, which a 32-bit virtual address space cannot
> provide above 4GiB.  Systems needing wider physical addressing are
> expected to use LPAE.
>
> Remove create_36bit_mapping() and the supersection definitions.  If
> firmware nevertheless advertises such a region on !LPAE,
> efi_create_mapping() rejects it before __pfn_to_phys() truncates its
> address to a low alias.  EFI runtime services remain disabled, but
> the kernel continues to boot.  LPAE kernels are unaffected.
>
> With no remaining !LPAE mappings above 4GiB, set MAX_PHYSMEM_BITS to
> 32 for !LPAE and retain 36 for LPAE, where phys_addr_t is 64-bit.
>
> Link: 
> https://lore.kernel.org/all/3c79d2dc-8fbd-40fc-8b2d-9d1b4f8ed34e@xxxxxxxxxxxxxxxx/
> Link: 
> https://lore.kernel.org/all/CAK8P3a2MCdUbN0QSb+M3g5_6HjPsaQwtKxFjADMZWomdry4-Ww@xxxxxxxxxxxxxx/
> Fixes: 14b80582c43e ("resource: Introduce alloc_free_mem_region()")
> Assisted-by: Claude:claude-fable-5
> Signed-off-by: Karl Mehltretter <kmehltretter@xxxxxxxxx>

Reviewed-by: Arnd Bergmann <arnd@xxxxxxxx>

Let's give others a few more workdays to comment, if nobody
has any concerns please add this to Russell's patch tracker
at https://www.arm.linux.org.uk/developer/patches/info.php

     Arnd