> -----Original Message-----
> From: Borislav Petkov <bp@xxxxxxxxx>
> Sent: Thursday, August 18, 2022 5:35 AM
> To: Kani, Toshi <toshi.kani@xxxxxxx>
> Cc: Justin He <Justin.He@xxxxxxx>; Ard Biesheuvel <ardb@xxxxxxxxxx>; Len
> Brown <lenb@xxxxxxxxxx>; James Morse <James.Morse@xxxxxxx>; Tony
> Luck <tony.luck@xxxxxxxxx>; Mauro Carvalho Chehab
> <mchehab@xxxxxxxxxx>; Robert Richter <rric@xxxxxxxxxx>; Robert Moore
> <robert.moore@xxxxxxxxx>; linux-acpi@xxxxxxxxxxxxxxx;
> linux-kernel@xxxxxxxxxxxxxxx; linux-edac@xxxxxxxxxxxxxxx; devel@xxxxxxxxxx;
> Rafael J . Wysocki <rafael@xxxxxxxxxx>; Shuai Xue
> <xueshuai@xxxxxxxxxxxxxxxxx>; Jarkko Sakkinen <jarkko@xxxxxxxxxx>;
> linux-efi@xxxxxxxxxxxxxxx; nd <nd@xxxxxxx>; stable@xxxxxxxxxx
> Subject: Re: [PATCH 2/2] EDAC/ghes: Modularize ghes_edac driver to remove
> the dependency on ghes
>
> On Wed, Aug 17, 2022 at 09:09:41PM +0000, Kani, Toshi wrote:
> > Since then, the change below enabled ghes_edac on Arm without this
> > known-good platforms check.
> >
> > commit eaa3a1d46 ("EDAC, ghes: Make platform-based whitelisting
> > x86-only")
>
> Bah, I had forgotten about that one...
>
> In any case, edac_mc_add_mc* is too late in the init path - that check should
> happen as the very first thing in the driver init function.
>
> And looking at the ARM64 EDAC drivers, they're only a couple: thunderx,
> xgene, bluefield, dmc-520... And I'd still prefer if their maintainers explicitly
> ACK such a change to call ghes_get_devices() (for a lack of a better idea) and
> not enable ghes_edac on them blindly.
Okay, will include above changes in next version, thanks for the reminder.
--
Cheers,
Justin (Jia He)
