[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <eb983a65-ca78-4290-bad2-3e8955de5d69@samsung.com>
Date: Fri, 19 Dec 2025 09:35:19 +0100
From: Marek Szyprowski <m.szyprowski@...sung.com>
To: Leon Romanovsky <leon@...nel.org>, Helge Deller <deller@....de>, "James
E.J. Bottomley" <James.Bottomley@...senpartnership.com>, Jason Gunthorpe
<jgg@...pe.ca>
Cc: linux-parisc@...r.kernel.org, linux-kernel@...r.kernel.org, Guenter
Roeck <linux@...ck-us.net>
Subject: Re: [PATCH] parisc: Set valid bit in high byte of 64‑bit physical address
On 18.12.2025 22:28, Leon Romanovsky wrote:
> On Thu, Dec 18, 2025, at 20:27, Helge Deller wrote:
>> On 12/18/25 13:08, Leon Romanovsky wrote:
>>> On 32‑bit systems, phys_addr_t is defined as u32. However, parisc
>>> expects physical addresses to be 64‑bit values so it can store a
>>> validity bit in the upper byte.
>>> ...
>>> Also remove the now‑obsolete macro.
>> Your patch is OK, but could you please keep the lpa() macro?
>> It's unrelated to your patch, and sometimes we need the lpa()
>> e.g. when adding debug code, so I'd prefer to keep it.
> The parch was already accepted and if Marek agrees, he can easily revert the deleted hunk and rebase my parch.
>
> However from upstream perspective, we don't keep code which is not used and if this macro would be function, we would get compilation warning for that.
>
> Isn't lpa(x/) equal to virt_to_phys(x)?
I can drop the lpa() related change, but let us know what is the
advantage of it compared to virt_to_phys()?
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
Powered by blists - more mailing lists