>-----Original Message----- >From: Shiju Jose <shiju.jose@xxxxxxxxxx> >Sent: 03 January 2025 18:33 >To: Dave Jiang <dave.jiang@xxxxxxxxx>; Jonathan Cameron ><jonathan.cameron@xxxxxxxxxx>; Borislav Petkov <bp@xxxxxxxxx> >Cc: linux-edac@xxxxxxxxxxxxxxx; linux-cxl@xxxxxxxxxxxxxxx; linux- >acpi@xxxxxxxxxxxxxxx; linux-mm@xxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; >tony.luck@xxxxxxxxx; rafael@xxxxxxxxxx; lenb@xxxxxxxxxx; >mchehab@xxxxxxxxxx; dan.j.williams@xxxxxxxxx; dave@xxxxxxxxxxxx; >alison.schofield@xxxxxxxxx; vishal.l.verma@xxxxxxxxx; ira.weiny@xxxxxxxxx; >david@xxxxxxxxxx; Vilas.Sridharan@xxxxxxx; leo.duran@xxxxxxx; >Yazen.Ghannam@xxxxxxx; rientjes@xxxxxxxxxx; jiaqiyan@xxxxxxxxxx; >Jon.Grimm@xxxxxxx; dave.hansen@xxxxxxxxxxxxxxx; >naoya.horiguchi@xxxxxxx; james.morse@xxxxxxx; jthoughton@xxxxxxxxxx; >somasundaram.a@xxxxxxx; erdemaktas@xxxxxxxxxx; pgonda@xxxxxxxxxx; >duenwen@xxxxxxxxxx; gthelen@xxxxxxxxxx; >wschwartz@xxxxxxxxxxxxxxxxxxx; dferguson@xxxxxxxxxxxxxxxxxxx; >wbs@xxxxxxxxxxxxxxxxxxxxxx; nifan.cxl@xxxxxxxxx; tanxiaofei ><tanxiaofei@xxxxxxxxxx>; Zengtao (B) <prime.zeng@xxxxxxxxxxxxx>; Roberto >Sassu <roberto.sassu@xxxxxxxxxx>; kangkang.shen@xxxxxxxxxxxxx; >wanghuiqiang <wanghuiqiang@xxxxxxxxxx>; Linuxarm ><linuxarm@xxxxxxxxxx> >Subject: RE: [PATCH v17 00/18] EDAC: Scrub: introduce generic EDAC RAS >control feature driver + CXL/ACPI-RAS2 drivers > [...] >> >> >>On 1/3/25 6:02 AM, Jonathan Cameron wrote: >>> On Fri, 3 Jan 2025 12:41:45 +0100 >>> Borislav Petkov <bp@xxxxxxxxx> wrote: >>> >>>> On Fri, Nov 22, 2024 at 06:03:57PM +0000, shiju.jose@xxxxxxxxxx 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 works for me. >> >>DJ >> >>> >>> 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)? > >Rebased, reordered and tested fine. Waiting for some information before >sharing the updated patches. Please find updated and reordered patches in https://github.com/shijujose4/linux/tree/edac-enhancement-ras-features_v18 Please note that EDAC patches are the same as in v17 other than updated, the kernel version to 6.14 in the documentation. > >>> > Thanks, >>> >>> Jonathan >> Thanks, Shiju