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

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

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