From: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>
To: "Michal Orzel" <michal.orzel@amd.com>, <xen-devel@lists.xenproject.org>
Cc: "Stefano Stabellini" <sstabellini@kernel.org>,
"Julien Grall" <julien@xen.org>,
"Bertrand Marquis" <bertrand.marquis@arm.com>,
"Volodymyr Babchuk" <Volodymyr_Babchuk@epam.com>,
<oleksii.kurochko@gmail.com>
Subject: Re: [for-4.20][PATCH 2/2] xen/arm: Fix build issue when CONFIG_PHYS_ADDR_T_32=y
Date: Tue, 28 Jan 2025 18:48:38 +0000 [thread overview]
Message-ID: <D7DXIXNODNSU.B17NMD5C6WNW@cloud.com> (raw)
In-Reply-To: <4788ed30-f182-4fd9-aad5-5faca3580e3b@amd.com>
On Mon Jan 27, 2025 at 5:14 PM GMT, Michal Orzel wrote:
>
>
> On 27/01/2025 18:03, Alejandro Vallejo wrote:
> >
> >
> > Hi,
> >
> > On Mon Jan 27, 2025 at 10:45 AM GMT, Michal Orzel wrote:
> >> On Arm32, when CONFIG_PHYS_ADDR_T_32 is set, a build failure is observed:
> >> arch/arm/platforms/vexpress.c: In function 'vexpress_smp_init':
> >> arch/arm/platforms/vexpress.c:102:12: error: format '%lx' expects argument of type 'long unsigned int', but argument 2 has type 'long long unsigned int' [-Werror=format=]
> >> 102 | printk("Set SYS_FLAGS to %"PRIpaddr" (%p)\n",
> >>
> >> When CONFIG_PHYS_ADDR_T_32 is set, paddr_t is defined as unsigned long.
> >> Commit 96f35de69e59 dropped __virt_to_maddr() which used paddr_t as a
> >> return type. Without a cast, the expression type is unsigned long long
> >> which causes the issue. Fix it.
> >>
> >> Fixes: 96f35de69e59 ("x86+Arm: drop (rename) __virt_to_maddr() / __maddr_to_virt()")
> >> Signed-off-by: Michal Orzel <michal.orzel@amd.com>
> >> ---
> >> xen/arch/arm/include/asm/mm.h | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/xen/arch/arm/include/asm/mm.h b/xen/arch/arm/include/asm/mm.h
> >> index f91ff088f6b1..a0d8e5afe977 100644
> >> --- a/xen/arch/arm/include/asm/mm.h
> >> +++ b/xen/arch/arm/include/asm/mm.h
> >> @@ -263,7 +263,7 @@ static inline void __iomem *ioremap_wc(paddr_t start, size_t len)
> >>
> >> #define virt_to_maddr(va) ({ \
> >> vaddr_t va_ = (vaddr_t)(va); \
> >> - (va_to_par(va_) & PADDR_MASK & PAGE_MASK) | (va_ & ~PAGE_MASK); \
> >> + (paddr_t)((va_to_par(va_) & PADDR_MASK & PAGE_MASK) | (va_ & ~PAGE_MASK)); \
> >> })
> >>
> >> #ifdef CONFIG_ARM_32
> >
> > Out of curiosity, why not make va_to_par() and __va_to_par() return paddr_t
> > rather than uint64_t? Then this cast would be unnecessary and the expression
> > end up as unsigned long.
> >
> > That would also cover any other uses outside this macro.
> >
> > Unless I'm missing something else...
> va_to_par() returns uint64_t because PAR_EL1 on Arm64 or PAR on Arm32 system registers are both 64bit.
> So, it would not make sense (also it would be confusing) for va_to_par() to return already casted value.
> The function ends with _par so it should reflect the register size as the name suggests. Macro is there
> to cast this value as it also takes into account PADDR_MASK and PAGE_MASK.
>
> ~Michal
I see. The point is to keep va_to_par() in sync with PAR's width then.
Fair enough then.
Cheers,
Alejandro
next prev parent reply other threads:[~2025-01-28 18:48 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-27 10:45 [for-4.20][PATCH 0/2] xen/arm CONFIG_PHYS_ADDR_T_32=y fixes Michal Orzel
2025-01-27 10:45 ` [for-4.20][PATCH 1/2] device-tree: bootfdt: Fix build issue when CONFIG_PHYS_ADDR_T_32=y Michal Orzel
2025-01-27 11:19 ` Julien Grall
2025-01-27 12:52 ` Michal Orzel
2025-01-27 16:27 ` Julien Grall
2025-01-27 17:15 ` Michal Orzel
2025-01-27 21:58 ` Julien Grall
2025-01-27 13:49 ` Luca Fancellu
2025-01-27 10:45 ` [for-4.20][PATCH 2/2] xen/arm: " Michal Orzel
2025-01-27 13:51 ` Luca Fancellu
2025-01-28 1:21 ` Stefano Stabellini
2025-01-27 17:03 ` Alejandro Vallejo
2025-01-27 17:14 ` Michal Orzel
2025-01-28 18:48 ` Alejandro Vallejo [this message]
2025-01-27 12:57 ` [for-4.20][PATCH 0/2] xen/arm CONFIG_PHYS_ADDR_T_32=y fixes Oleksii Kurochko
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=D7DXIXNODNSU.B17NMD5C6WNW@cloud.com \
--to=alejandro.vallejo@cloud.com \
--cc=Volodymyr_Babchuk@epam.com \
--cc=bertrand.marquis@arm.com \
--cc=julien@xen.org \
--cc=michal.orzel@amd.com \
--cc=oleksii.kurochko@gmail.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/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.