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

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

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.