[PATCH-next] arm: fix clang build warning in include/asm/memory.h

Russell King (Oracle) linux at armlinux.org.uk
Fri Mar 15 07:46:26 PDT 2024


On Fri, Mar 15, 2024 at 02:16:23PM +0100, Linus Walleij wrote:
> On Fri, Mar 15, 2024 at 11:08 AM Russell King (Oracle)
> <linux at armlinux.org.uk> wrote:
> > On Fri, Mar 15, 2024 at 08:40:28AM +0100, Linus Walleij wrote:
> > > +1 and I would probably use this as well:
> > >
> > > <linux/limits.h>
> > >
> > > #define IDMAP_INVALID_ADDR    PHYS_ADDR_MAX
> > >
> > > if (IS_ENABLED(CONFIG_PHYS_ADDR_T_64BIT) && addr > PHYS_ADDR_MAX)
> > >     addr = IDMAP_INVALID_ADDR;
> > >
> > > Because then it is clear what is going on: we are capping to the max physical
> > > address.
> > >
> > > PHYS_ADDR_MAX is defined to (~(phys_addr_t)0) which on
> > > ARM is (~(u32)0).
> >
> > ... which is _not_ the same as (u32)~0, so using PHYS_ADDR_MAX is not
> > appropriate.
> 
> Attention to detail! Thanks Russell.
> 
> However U32_MAX is
> #define U32_MAX         ((u32)~0U)
> 
> So that should work and also convey the attention I think?

If you want to use that to define IDMAP_INVALID_ADDR then yes. If you're
thinking about getting rid of IDMAP_INVALID_ADDR, then I think that
would reduce code readability, because the idea here is that addresses
above the 32-bit virtual space are invalid for IDMAP, and just using
U32_MAX is a rather opaque way to convey that.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!



More information about the linux-arm-kernel mailing list