Re: EDAC instances probing

[Borislav Petkov <bp@alien8.de>]

On Fri, Dec 11, 2020 at 02:35:20PM -0600, Yazen Ghannam wrote:
> I think it's okay. But it could even be a single boolean rather than a
> bitmap. At least for amd64_edac_mod, the driver will probe all the
> Northbridge/Data Fabric instances even if some fail.

Ah, I see what you mean. amd64_edac does the all-or-nothing thing where
when it fails probing an instance, it unwinds. Yeah, I guess we can make
this a bool to say "we probed already".

> I don't know if the same applies to other EDAC modules.

I'll have to have a look.

> Does this issue affect other modules?

Those:

$ git grep x86_match_cpu drivers/edac/
drivers/edac/amd64_edac.c:3662: if (!x86_match_cpu(amd64_cpuids))
drivers/edac/i10nm_base.c:281:  id = x86_match_cpu(i10nm_cpuids);
drivers/edac/pnd2_edac.c:1557:  id = x86_match_cpu(pnd2_cpuids);
drivers/edac/sb_edac.c:3513:    id = x86_match_cpu(sbridge_cpuids);
drivers/edac/skx_base.c:659:    id = x86_match_cpu(skx_cpuids);

> Also, would it make sense to go back to PCI device probing? We've still
> needed to add PCI IDs for almost every model group. Probing by PCI
> device should help us avoid this issue and also prevent some messages
> where PCI IDs aren't found for supported families. For example, we had
> that problem when Family 17h Models 30h-3Fh came out. The module would
> load because it recognized Family 17h, but it would fail because the new
> PCI IDs for Models 30h-3Fh were not recognized.

Just like in the other mail I just sent you.

So that's the thing - we converted to x86_match_cpu() because adding
all those PCI IDs was tedious and using f/m/s would need a lot less
enablement so that the drivers work out of the box most of the time.

It's a tradeoff.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette