linux-kernel - Re: [PATCH v2 1/2] EDAC/amd64: Add support for AMD family 1Ah-based newer models

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ea877d34-1e06-4a0f-b51c-92b706d06c09@amd.com>
Date: Mon, 25 Aug 2025 09:30:17 -0500
From: "Naik, Avadhut" <avadnaik@....com>
To: Borislav Petkov <bp@...en8.de>, Avadhut Naik <avadhut.naik@....com>
Cc: linux-edac@...r.kernel.org, yazen.ghannam@....com,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] EDAC/amd64: Add support for AMD family 1Ah-based
 newer models



On 8/18/2025 16:22, Borislav Petkov wrote:
> On Thu, Aug 07, 2025 at 08:14:53PM +0000, Avadhut Naik wrote:
>> Add support for family 1Ah-based models 50h-57h, 90h-9Fh, A0h-AFh, and
>> C0h-C7h.
>>
>> Signed-off-by: Avadhut Naik <avadhut.naik@....com>
>> ---
>>  drivers/edac/amd64_edac.c | 20 ++++++++++++++++++++
>>  drivers/edac/amd64_edac.h |  2 +-
>>  2 files changed, 21 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
>> index 07f1e9dc1ca7..2f6ab783bf20 100644
>> --- a/drivers/edac/amd64_edac.c
>> +++ b/drivers/edac/amd64_edac.c
>> @@ -3923,6 +3923,26 @@ static int per_family_init(struct amd64_pvt *pvt)
>>  			pvt->ctl_name           = "F1Ah_M40h";
>>  			pvt->flags.zn_regs_v2   = 1;
>>  			break;
>> +		case 0x50 ... 0x57:
>> +			pvt->ctl_name           = "F1Ah_M50h";
>> +			pvt->max_mcs            = 16;
>> +			pvt->flags.zn_regs_v2   = 1;
>> +			break;
>> +		case 0x90 ... 0x9f:
>> +			pvt->ctl_name           = "F1Ah_M90h";
>> +			pvt->max_mcs            = 8;
>> +			pvt->flags.zn_regs_v2   = 1;
>> +			break;
>> +		case 0xa0 ... 0xaf:
>> +			pvt->ctl_name           = "F1Ah_MA0h";
>> +			pvt->max_mcs            = 8;
>> +			pvt->flags.zn_regs_v2   = 1;
>> +			break;
>> +		case 0xc0 ... 0xc7:
>> +			pvt->ctl_name           = "F1Ah_MC0h";
>> +			pvt->max_mcs            = 16;
>> +			pvt->flags.zn_regs_v2   = 1;
>> +			break;
>>  		}
> 
> Oh boy, this pvt->ctl_name is ridiculous: we're collecting a zoo of string
> objects where this thing can simply be scnprintf()-ed once at driver init and
> then the pointer handed in to mci->ctl_name.
> 
> Something like
> 
> static char *ctl_name[MAX_CTL_NAMELEN]; 
> 
> or so. And then
> 
> 	scnprintf(...)
> 
> into it based on family and model.
> 
> Can you pls do that as a cleanup upfront?
> 
> This is slowly getting out of hand.
> 
> And then you can group them together:
> 
> case 0x50 ... 0x57:
> case 0xc0 ... 0xc7:
> 	pvt->max_mcs            = 16;
> 	pvt->flags.zn_regs_v2   = 1;
> 	break;
> 
> ...
> 
> and so on.
> 
> So that this function turns back into something saner again.
> 
> Thx.
> 
> 
> 
> 
> 
>>  		break;
>>  
>> diff --git a/drivers/edac/amd64_edac.h b/drivers/edac/amd64_edac.h
>> index 17228d07de4c..d70b8a8d0b09 100644
>> --- a/drivers/edac/amd64_edac.h
>> +++ b/drivers/edac/amd64_edac.h
>> @@ -96,7 +96,7 @@
>>  /* Hardware limit on ChipSelect rows per MC and processors per system */
>>  #define NUM_CHIPSELECTS			8
>>  #define DRAM_RANGES			8
>> -#define NUM_CONTROLLERS			12
>> +#define NUM_CONTROLLERS			16
> 
> I've asked this before but can we read out the number of controllers from the
> hw somewhere instead of diddling with this silly define all the time?
> 
> Thx.
> 

Will take a look at this!

-- 
Thanks,
Avadhut Naik