Re: [PATCH v9 1/7] RAS/AMD/ATL: Always build PRM address translation support

On Fri, Jul 31, 2026 at 04:55:23PM -0700, Borislav Petkov wrote:
> On Thu, Jul 30, 2026 at 03:48:28PM -0400, Yazen Ghannam wrote:
> > PRM (Platform Runtime Mechanism) is the only address translation method for
> > current and future AMD systems. The library should therefore always include
> > it.
> > 
> > The PRM helpers in <linux/prmt.h> already provide stubs that return an
> > error when CONFIG_ACPI_PRMT is disabled. This lets prm.c build and link
> > in all configurations. The library then falls back to native translation
> > at runtime when no PRM handler is available.
> > 
> > Drop the CONFIG_AMD_ATL_PRM option. Build prm.o unconditionally and remove
> > the now-unneeded stub for prm_umc_norm_to_sys_addr().
> > 
> > Add -EOPNOTSUPP as "PRM not available". The acpi_call_prm_handler() stub
> > returns this when CONFIG_ACPI_PRMT=n.
> 
> Please tell AI to NOT write what the patch does. :-)

Ha, I try, but I make the same mistake myself. :P

That's probably obvious, because I reviewed the commit message and
signed off on it. :)

> 
> New commit message:
> 
> "RAS/AMD/ATL: Make PRM address translation support builtin
> 
> PRM (Platform Runtime Mechanism) is the only address translation method for
> current and future AMD systems. The library should therefore always include
> it.
> 
> The PRM helpers in <linux/prmt.h> already provide stubs that return an error
> when CONFIG_ACPI_PRMT is disabled. Make prm.c builtin. The library then falls
> back to native translation at runtime when no PRM handler is available."
> 

Looks good to me.

> Yah, looking at prm.c, I'm wondering why we even Kconfigged it. Oh well...

IIRC, it was to be more modular for custom kernel builds. Of course, now
we probably should put the 'native' translation code behind a config
option. There's a lot more of that, and it's only used for legacy
systems.

Thanks,
Yazen