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)? > > Thanks, > > Jonathan
