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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250103130213.00006abd@huawei.com>
Date: Fri, 3 Jan 2025 13:02:13 +0000
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: Borislav Petkov <bp@...en8.de>
CC: <shiju.jose@...wei.com>, <linux-edac@...r.kernel.org>,
	<linux-cxl@...r.kernel.org>, <linux-acpi@...r.kernel.org>,
	<linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>, <tony.luck@...el.com>,
	<rafael@...nel.org>, <lenb@...nel.org>, <mchehab@...nel.org>,
	<dan.j.williams@...el.com>, <dave@...olabs.net>, <dave.jiang@...el.com>,
	<alison.schofield@...el.com>, <vishal.l.verma@...el.com>,
	<ira.weiny@...el.com>, <david@...hat.com>, <Vilas.Sridharan@....com>,
	<leo.duran@....com>, <Yazen.Ghannam@....com>, <rientjes@...gle.com>,
	<jiaqiyan@...gle.com>, <Jon.Grimm@....com>, <dave.hansen@...ux.intel.com>,
	<naoya.horiguchi@....com>, <james.morse@....com>, <jthoughton@...gle.com>,
	<somasundaram.a@....com>, <erdemaktas@...gle.com>, <pgonda@...gle.com>,
	<duenwen@...gle.com>, <gthelen@...gle.com>, <wschwartz@...erecomputing.com>,
	<dferguson@...erecomputing.com>, <wbs@...amperecomputing.com>,
	<nifan.cxl@...il.com>, <tanxiaofei@...wei.com>, <prime.zeng@...ilicon.com>,
	<roberto.sassu@...wei.com>, <kangkang.shen@...urewei.com>,
	<wanghuiqiang@...wei.com>, <linuxarm@...wei.com>
Subject: Re: [PATCH v17 00/18] EDAC: Scrub: introduce generic EDAC RAS
 control feature driver + CXL/ACPI-RAS2 drivers

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

> On Fri, Nov 22, 2024 at 06:03:57PM +0000, shiju.jose@...wei.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