>-----Original Message----- >From: Dave Jiang <dave.jiang@intel.com> >Sent: 03 January 2025 15:50 >To: Jonathan Cameron <jonathan.cameron@huawei.com>; Borislav Petkov ><bp@alien8.de> >Cc: Shiju Jose <shiju.jose@huawei.com>; linux-edac@vger.kernel.org; linux- >cxl@vger.kernel.org; linux-acpi@vger.kernel.org; linux-mm@kvack.org; linux- >kernel@vger.kernel.org; tony.luck@intel.com; rafael@kernel.org; >lenb@kernel.org; mchehab@kernel.org; dan.j.williams@intel.com; >dave@stgolabs.net; alison.schofield@intel.com; vishal.l.verma@intel.com; >ira.weiny@intel.com; david@redhat.com; Vilas.Sridharan@amd.com; >leo.duran@amd.com; Yazen.Ghannam@amd.com; rientjes@google.com; >jiaqiyan@google.com; Jon.Grimm@amd.com; dave.hansen@linux.intel.com; >naoya.horiguchi@nec.com; james.morse@arm.com; jthoughton@google.com; >somasundaram.a@hpe.com; erdemaktas@google.com; pgonda@google.com; >duenwen@google.com; gthelen@google.com; >wschwartz@amperecomputing.com; dferguson@amperecomputing.com; >wbs@os.amperecomputing.com; nifan.cxl@gmail.com; tanxiaofei ><tanxiaofei@huawei.com>; Zengtao (B) <prime.zeng@hisilicon.com>; Roberto >Sassu <roberto.sassu@huawei.com>; kangkang.shen@futurewei.com; >wanghuiqiang <wanghuiqiang@huawei.com>; Linuxarm ><linuxarm@huawei.com> >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@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 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. Thanks, Shiju >> > Thanks, >> >> Jonathan >
>-----Original Message----- >From: Shiju Jose <shiju.jose@huawei.com> >Sent: 03 January 2025 18:33 >To: Dave Jiang <dave.jiang@intel.com>; Jonathan Cameron ><jonathan.cameron@huawei.com>; Borislav Petkov <bp@alien8.de> >Cc: linux-edac@vger.kernel.org; linux-cxl@vger.kernel.org; linux- >acpi@vger.kernel.org; linux-mm@kvack.org; linux-kernel@vger.kernel.org; >tony.luck@intel.com; rafael@kernel.org; lenb@kernel.org; >mchehab@kernel.org; dan.j.williams@intel.com; dave@stgolabs.net; >alison.schofield@intel.com; vishal.l.verma@intel.com; ira.weiny@intel.com; >david@redhat.com; Vilas.Sridharan@amd.com; leo.duran@amd.com; >Yazen.Ghannam@amd.com; rientjes@google.com; jiaqiyan@google.com; >Jon.Grimm@amd.com; dave.hansen@linux.intel.com; >naoya.horiguchi@nec.com; james.morse@arm.com; jthoughton@google.com; >somasundaram.a@hpe.com; erdemaktas@google.com; pgonda@google.com; >duenwen@google.com; gthelen@google.com; >wschwartz@amperecomputing.com; dferguson@amperecomputing.com; >wbs@os.amperecomputing.com; nifan.cxl@gmail.com; tanxiaofei ><tanxiaofei@huawei.com>; Zengtao (B) <prime.zeng@hisilicon.com>; Roberto >Sassu <roberto.sassu@huawei.com>; kangkang.shen@futurewei.com; >wanghuiqiang <wanghuiqiang@huawei.com>; Linuxarm ><linuxarm@huawei.com> >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@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 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
On Fri, Jan 03, 2025 at 07:17:13PM +0000, Shiju Jose wrote:
> 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.
If you want patches applied, you send them as mails to the mailing list. Not
some branch on github. Unless I should take the v17 stuff...
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
© 2016 - 2026 Red Hat, Inc.