Re: [PATCH] parisc: Set valid bit in high byte of 64‑bit physical address

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Fri, 2025-12-19 at 09:35 +0100, Marek Szyprowski wrote:
> 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()?

Um, well same as on every architecture: virt_to_phys only gives correct
results on the offset map since it's defined as an offset map
subtraction; lpa() gives the the CPU view of the mapping through the
page table entries, so is correct even in the vmap (and iomap, etc)
range.

Regards,

James