> > This code was originally developend by Qiuxu as an add-on to an EDAC > > driver. But not everyone wants to run an EDAC driver, > > Interesting, what's so bad about EDAC drivers that makes you move all that > functionality which is clearly RAS/MCE/EDAC into some random platform driver? Mostly that not everyone wants to run EDAC drivers. > There's also arch/x86/kernel/cpu/mce/intel.c and that doesn't fit either? Plausibly. But it is model specific. Needs to know how h/w banks are shared between logical CPUs so it can get the time comparisons right when a shared bank reports BFF overflow on different CPUs. Intel doesn't have any enumeration for bank sharing, and changes things often. It's also just for one (not yet released) CPU model today. So, building it into the MCE code would be overhead for almost everyone. But I can move it if you think that is a better place for it. -Tony
On Tue, Aug 25, 2026 at 06:55:27PM +0000, Luck, Tony wrote:
> Mostly that not everyone wants to run EDAC drivers.
Just because or is there a particular reason?
Because we could try to address those reasons if they were more concrete and
valid...
> Plausibly. But it is model specific. Needs to know how h/w banks are shared
> between logical CPUs so it can get the time comparisons right when a shared
> bank reports BFF overflow on different CPUs. Intel doesn't have any enumeration
> for bank sharing, and changes things often.
>
> It's also just for one (not yet released) CPU model today. So, building it into the MCE
> code would be overhead for almost everyone.
>
> But I can move it if you think that is a better place for it.
Well, my angle is: we already have soo much RAS glue in the kernel so adding
a *platform* driver for it is simply unnecessary.
For example, drivers/edac/mce_amd.c is the whole AMD MCE decoding and even
though it is in drivers/edac/, it is not really an EDAC driver. So your BFFs
(wonderful acronym btw :-P) would likely fit there too.
And looking at the code, it looks very familiar to that thing - simply
a notifier callback with a bunch of logic to decode and report the error.
And there's drivers/ras/ too.
And we already have the whole machinery around it so let's move it somewhere
more fitting than in yet another new place pls.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
© 2016 - 2026 Red Hat, Inc.