Re: [PATCH] RAS/AMD/ATL: Decrease message about unknown DF revision to debug

[Yazen Ghannam <yazen.ghannam@amd.com>]

On Tue, Mar 10, 2026 at 09:58:18AM -0500, Mario Limonciello wrote:
> On 3/10/26 7:54 AM, Yazen Ghannam wrote:
> > On Sat, Mar 07, 2026 at 04:12:31PM +0100, Borislav Petkov wrote:
> > > On Sat, Mar 07, 2026 at 09:49:10AM -0500, Yazen Ghannam wrote:
> > > > On Fri, Mar 06, 2026 at 04:49:47PM +0100, Borislav Petkov wrote:
> > > > > On Fri, Mar 06, 2026 at 09:40:06AM -0600, Mario Limonciello wrote:
> > > > > > But don't you need to use UMC to discover that?  Chicken and egg type of
> > > > > > issue.
> > > > > 
> > > > > Probably...
> > > > > 
> > > > > And we already do that in amd64_edac. So perhaps we could export an API or so.
> > > > > Yazen might have an idea...
> > > > > 
> > > > 
> > > > How about having EDAC load ATL when ready?
> > > 
> > > The thing is, AMD_ATL can also be built-in so then request_module doesn't make
> > > sense.
> > > 
> > > Which means, if we have to "tie" it to amd64_edac detection, we'd have to make
> > > it synchronize its Kconfig setting to the CONFIG_EDAC_AMD64 setting.
> > > 
> > > Or we could simply say that AMD_ATL is a module only because if anything needs
> > > it, then anything should request it. And that makes sense because the address
> > > translation should be present only when something else loads which is at all
> > > capable of presenting addresses which can be translated.
> > > 
> > > IOW, AMD_ATL should not be builtin at all because, well, it doesn't make any
> > > sense for it to be. IOW, its existence alone on the system makes a little
> > > sense if there's no address producer like amd64_edac or whatever else calls
> > > amd_convert_umc_mca_addr_to_sys_addr()...
> > > 
> > > Hmmm.
> > > 
> > > It sure sounds weird...
> > > 
> > 
> > So AMD_ATL *can* be built-in, but it is default 'N'. CONFIG_EDAC_AMD64
> > has 'imply AMD_ATL', so CONFIG_AMD_ATL=CONFIG_EDAC_AMD64.
> > 
> > If CONFIG_EDAC_AMD64=m, then CONFIG_AMD_ATL=m. I think this would be the
> > default for most users. EDAC will fail to load on systems without DRAM
> > ECC, so AMD_ATL won't load either.
> > 
> > If CONFIG_EDAC_AMD64=y, then CONFIG_AMD_ATL=y. I expect that a user that
> > wants EDAC built-in knows their system will use it.
> > 
> > Thanks,
> > Yazen
> 
> Are there "going" to be other consumers of AMD_ATL planned?  I wonder if it
> should just be structured as part of amd64_edac and only registered once we
> know there is ECC support.
>

Yes, actually address translation was once part of amd64_edac. But there
is so much code that it was nice to move it to a separate library.
Another example of this decoupling is with ACPI_ADXL that Intel uses.

There is another user of AMD_ATL: RAS_FMPM.

Also, I do have it in mind that AMD_ATL can be used by other places or
independently. I have some old WIP where we use it with MCE to do
preemptive page offlining.

EDAC for x86 is mostly counting and decoding. You could leverage address
translation without wanting to use EDAC. And you can use EDAC without
address translation.

Thanks,
Yazen