RE: [RESEND PATCH v3 5/9] EDAC: Don't load chipset-specific edac drivers when ghes_edac is preferred

Kani, Toshi
2022-08-25T23:39:38Z

On Thursday, August 25, 2022 3:46 AM, Justin He wrote:
> > ghes_get_devices() changing multiple times in the series is
> > confusing to me. Can you simply introduce ghes_get_devices()
> > and ghes_preferred() in the right state in a patch? Perhaps, patch #2, #5,
> > #6 can collapse to introduce the two funcs?
>
> My purpose was to make it easy for review. I am ok to merge these patches
> into one.

This series starts with your original patchset and then has additional
patches to address the issues with the original patchset. The number
of the patches continues to increase in this way... You do not need to
record the history of discussions and design changes in the series.

> > The rest of patch #5 adding the call to ghes_edac_preferred() into other edac
> > drivers can remain as a separate patch.
>
> Okay, I assume you mean to merge all of the ghes_edac_preferred()
> checking for intel and
> Arm edac drivers into 1 separate patch, am I understanding well?

No, that's not what I meant.

ghes_get_devices() and ghes_edac_preferred() look good to me after
all patches are applied. So, instead of introducing the original design of
ghes_get_devices() and then changing its design multiple times in the
series, please simply add the final version of ghes_get_devices() and
ghes_edac_preferred() in a single patch. They are small functions anyway.

That is, your series includes something like:
- PATCH: Add ghes_get_devices() and ghes_edac_preferred() interfaces
- PATCH: Add ghes_edac_preferred check to chipset-specific edac drivers

Toshi