linux-kernel - RE: [PATCH 4/7] EDAC/{skx_common,imh}: Add EDAC driver for Intel Diamond Rapids servers

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: <SJ1PR11MB608363D7FBC9BF58DE3FFACCFCD7A@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date: Wed, 19 Nov 2025 17:05:15 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: Borislav Petkov <bp@...en8.de>, "Zhuo, Qiuxu" <qiuxu.zhuo@...el.com>
CC: "Lai, Yi1" <yi1.lai@...el.com>, "linux-edac@...r.kernel.org"
	<linux-edac@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 4/7] EDAC/{skx_common,imh}: Add EDAC driver for Intel
 Diamond Rapids servers

> Isn't that what we do all the time anyway? Make sure the kernel works on new
> hardware and so on.
>
> I'd understand if adding this new support would mean uglifying i10nm_edac but
> just because you can't test it on old hw sounds a bit iffy. By that logic we
> should simply spit out a new driver for every new hw generation and in the
> end, that strategy will come back to bite you because you'll end up
> maintaining a pile of duplicated drivers.
>
> So I hope there are more valid reasons justifying a new driver than just
> "validation."

Periodically its time to stop heaping more uglification onto the current driver
and cut a new one.

sb_edac.c (the "sb" stood for Sandy Bridge) got updates for Ivybridge, Haswell, Broadwell.

Skylake/Cascade Lake was an inflection point and so skx_edac.c was born.

There was enough changes in Icelake to warrant a new driver, and rather than naming
it based on the Icellake name I called it i10nm_edac.c (which given how long Intel kept
building on 10nm and derivatives turned out surprisingly accurate). But in this case there
was a lot of code that could be shared. It was split out into skx_edac_common.c

i10nm_edac.c has had a good run: Icelake, Sapphire Rapids, Emerald Rapids, Granite
Rapids, Sierra Forest and the upcoming Clearwater Forest.

But its time to stop piling on more model specific bits. The new driver still uses plenty of
the shared code in skx_edac_common.c ... so changes there need to be validated on
seven old platforms.

-Tony