All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Nathan Chancellor <nathan@kernel.org>,
	Yipeng Zou <zouyipeng@huawei.com>,
	ndesaulniers@google.com, morbo@google.com,
	justinstitt@google.com, ssantosh@kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH-next] arm: fix clang build warning in include/asm/memory.h
Date: Fri, 15 Mar 2024 14:46:26 +0000	[thread overview]
Message-ID: <ZfRfQmkG8hBw+VNT@shell.armlinux.org.uk> (raw)
In-Reply-To: <CACRpkdbxnt5RBTM4eqvq9rTCm2DTjH9BhotJQ_xG3aksrXkE6g@mail.gmail.com>

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@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!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2024-03-15 14:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-14  7:54 [PATCH-next] arm: fix clang build warning in include/asm/memory.h Yipeng Zou
2024-03-15  0:43 ` Nathan Chancellor
2024-03-15  7:40   ` Linus Walleij
2024-03-15 10:08     ` Russell King (Oracle)
2024-03-15 13:16       ` Linus Walleij
2024-03-15 14:46         ` Russell King (Oracle) [this message]
2024-03-19  3:13     ` Yipeng Zou
2024-03-19  3:16   ` Yipeng Zou
2024-03-19  3:38     ` Yipeng Zou
2024-03-19 14:46       ` Nathan Chancellor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZfRfQmkG8hBw+VNT@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=justinstitt@google.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=morbo@google.com \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=ssantosh@kernel.org \
    --cc=zouyipeng@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.