Re: [PATCH v17 00/18] EDAC: Scrub: introduce generic EDAC RAS control feature driver + CXL/ACPI-RAS2 drivers

Jonathan Cameron
2025-01-03T13:02:23Z

On Fri, 3 Jan 2025 12:41:45 +0100
Borislav Petkov <bp@alien8.de> wrote:

> On Fri, Nov 22, 2024 at 06:03:57PM +0000, shiju.jose@huawei.com wrote:
> > drivers/edac/Makefile | 1 +
> > drivers/edac/ecs.c | 207 +++
> > drivers/edac/edac_device.c | 183 ++
> > drivers/edac/mem_repair.c | 492 +++++
> > drivers/edac/scrub.c | 209 +++
> > drivers/ras/Kconfig | 10 +
> > drivers/ras/Makefile | 1 +
> > drivers/ras/acpi_ras2.c | 385 ++++
> > include/acpi/ras2_acpi.h | 45 +
> > include/cxl/features.h | 48 +
> > include/cxl/mailbox.h | 45 +-
> > include/linux/edac.h | 238 +++
> > include/uapi/linux/cxl_mem.h | 3 +
>
> So what's the plan here? Am I supposed to merge the EDAC/RAS bits through the
> RAS tree and then give folks an immutable branch or how do we want to proceed
> here?
>

Dave Jiang / Rafael, what would work best for the two of you?

To me Boris' suggestion makes sense, particularly as that
avoids the complexity of CXL get/set features being in multiple series.

I think the split that would make sense is:

EDAC immutable branch for:
1: EDAC: Add support for EDAC device features control
2: Add scrub control feature
3: EDAC: Add ECS control feature
15: EDAC: Add memory repair control feature

ACPI merges EDAC immutable +
13: ACPI:RAS2: Add ACPI RAS2 driver
14: ras: mem: Add memory ACPI RAS2 driver

CXL merges EDAC immutable +
4: cxl: Refactor user ioctl command path from mds to mailbox
5: cxl: Add Get Supported Features command for kernel usage
6: cxl/mbox: Add GET_FEATURE mailbox command
7: cxl: Add Get Feature command support for user submission
8: cxl/mbox: Add SET_FEATURE mailbox command
9: cxl: Add Set Feature command support for user submission
10: cxl: Add UUIDs for the CXL RAS features
11: cxl/memfeature: Add CXL memory device patrol scrub control feature
12: cxl/memfeature: Add CXL memory device ECS control feature
16: cxl/mbox: Add support for PERFORM_MAINTENANCE mailbox command
17: cxl/memfeature: Add CXL memory device soft PPR control feature
18: cxl/memfeature: Add CXL memory device memory sparing control feature

That does mean that the actual drivers/edac/ specific drivers land
via the ACPI and CXL trees only, but without another layer of immutable branches
we can't avoid that. Might cause merge conflicts in Kconfig/Makefiles but otherwise
shouldn't be too bad.

There is going to be some noise in documentation as examples are added
to the docs with the actual drivers (whereas generic docs are introduced
with the infrastructure). I think that will work out though.
Shiju, could you spin this ordering up and check it all works
(incorporating Dave's updates to the GET / SET feature)?

Thanks,

Jonathan