linux-kernel - Re: [PATCH 4/6] EDAC/altera: Add IO96B ECC support for Agilex5 SoCFPGA

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] [day] [month] [year] [list]

Message-ID: <24d2beec-129e-4545-b777-c1c717be956c@altera.com>
Date: Fri, 31 Oct 2025 19:52:41 +0800
From: Niravkumar L Rabara <niravkumarlaxmidas.rabara@...era.com>
To: Borislav Petkov <bp@...en8.de>
Cc: dinguyen@...nel.org, matthew.gerlach@...era.com, robh@...nel.org,
 krzk+dt@...nel.org, conor+dt@...nel.org, tony.luck@...el.com,
 linux-edac@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/6] EDAC/altera: Add IO96B ECC support for Agilex5
 SoCFPGA

On 30/10/2025 10:30 pm, Borislav Petkov wrote:
> On Tue, Oct 28, 2025 at 05:22:30PM +0800,niravkumarlaxmidas.rabara@...era.com wrote:
>> diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
>> index 39352b9b7a7e..33a9fccde2fe 100644
>> --- a/drivers/edac/Kconfig
>> +++ b/drivers/edac/Kconfig
>> @@ -410,6 +410,16 @@ config EDAC_ALTERA_SDRAM
>>   	  preloader must initialize the SDRAM before loading
>>   	  the kernel.
>>   
>> +config EDAC_ALTERA_IO96B
>> +	bool "Altera I096B ECC"
> Is this and the other new Kconfig symbols you're adding absolutely needed?
> 
> IOW, why can't the driver simply load on that new hw without needing Kconfig
> symbols at all?
> 
> What are they really saving?
> 
> Thx.
> 
> -- Regards/Gruss, Boris.

Hi Boris,

Thanks for your review.
Your point is absolutely valid — I was initially hesitant to introduce a 
different flow in the common altera_edac.c driver, so I followed the 
existing architecture where each ECC device has its own Kconfig entry 
and corresponding #ifdef blocks in the code.

In terms of savings, this approach mainly avoids compiling code based on 
Kconfig selection.

If the preferred approach is to detect and handle the new hardware 
without adding a separate Kconfig symbol, I’ll revise the patch accordingly.

In next version, I also need to address Krzysztof’s review comments 
regarding the introduction of new ECC device names in the DT bindings.

Thanks,
Nirav