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

[Mario Limonciello <mario.limonciello@amd.com>]

On 3/10/26 11:52 AM, Yazen Ghannam wrote:
> 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

OK.

I don't think the assertion that amd-atl won't load by default on most 
systems without ECC is correct.  It has a modalias that looks for 
features (X86_FEATURE_ZEN specifically).

alias:          cpu:type:x86,ven*fam*mod*:feature:*00FC*
alias:          cpu:type:x86,ven*fam*mod*:feature:*0223*

If you look at this all in a vacuum - is turning down the messaging to 
debug for amd-atl so bad?