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

Shiju Jose
2025-01-03T18:33:00Z

>-----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
>