From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D4B8BC0218D for ; Wed, 29 Jan 2025 12:28:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EE16A28005A; Wed, 29 Jan 2025 07:28:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E6A25280047; Wed, 29 Jan 2025 07:28:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CBCBE28005A; Wed, 29 Jan 2025 07:28:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id A2BC6280047 for ; Wed, 29 Jan 2025 07:28:17 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 2B27C80128 for ; Wed, 29 Jan 2025 12:28:17 +0000 (UTC) X-FDA: 83060417034.12.0E187E5 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by imf27.hostedemail.com (Postfix) with ESMTP id F0F5C40004 for ; Wed, 29 Jan 2025 12:28:13 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf27.hostedemail.com: domain of shiju.jose@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=shiju.jose@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738153694; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=IZA3JXj36LnLXO17b3OBBoYGPSCTRV7flwPofAWcZHA=; b=ncUvvyRUG43Lg5wQBCKgH3puVoT+EtAuFA3gLy/uOQZ2utbBQsZrqbbjCPP3q3W6UHjjSQ 1t8c7TxAb1ERI6KwKp178Ikx6xBPOiKdb84TxVhJASAArBIPU0QVWUzBzSyal1frrlvG9n GBHhTB6pVtZRa0/2e6OYtZNSXrDYntA= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf27.hostedemail.com: domain of shiju.jose@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=shiju.jose@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738153694; a=rsa-sha256; cv=none; b=l4Fbgi56X5pczS9v6WTtpMnC6NoCMlpEnoHe3a0xc/5xJVA7TQ8/1sbNbnTts3zxVGYEJO ukLZYIt/wdrzHU/kgXkKbuVyfj1q7U/PGimPzVXAdJtuSHKGI1yn1+1Qq+LU78iGaJ3Ntz P3s+2nj36JiA8zF59BPOOj8O1DE3gkY= Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4YjhG56mK7z6M4V7; Wed, 29 Jan 2025 20:26:05 +0800 (CST) Received: from frapeml500008.china.huawei.com (unknown [7.182.85.71]) by mail.maildlp.com (Postfix) with ESMTPS id 5329C140B30; Wed, 29 Jan 2025 20:28:11 +0800 (CST) Received: from frapeml500007.china.huawei.com (7.182.85.172) by frapeml500008.china.huawei.com (7.182.85.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Wed, 29 Jan 2025 13:28:11 +0100 Received: from frapeml500007.china.huawei.com ([7.182.85.172]) by frapeml500007.china.huawei.com ([7.182.85.172]) with mapi id 15.01.2507.039; Wed, 29 Jan 2025 13:28:11 +0100 From: Shiju Jose To: Dan Williams , "linux-edac@vger.kernel.org" , "linux-cxl@vger.kernel.org" , "linux-acpi@vger.kernel.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" CC: "bp@alien8.de" , "tony.luck@intel.com" , "rafael@kernel.org" , "lenb@kernel.org" , "mchehab@kernel.org" , "dave@stgolabs.net" , "Jonathan Cameron" , "dave.jiang@intel.com" , "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 , "Zengtao (B)" , "Roberto Sassu" , "kangkang.shen@futurewei.com" , wanghuiqiang , Linuxarm Subject: RE: [PATCH v18 15/19] cxl/memfeature: Add CXL memory device patrol scrub control feature Thread-Topic: [PATCH v18 15/19] cxl/memfeature: Add CXL memory device patrol scrub control feature Thread-Index: AQHbYDQzwb2+msEnKkOZzkWMDvDlzLMmbr6AgAQZmTCAAMm+AIACfVPQ Date: Wed, 29 Jan 2025 12:28:10 +0000 Message-ID: <6b897863e04e4e588f1af318e4292739@huawei.com> References: <20250106121017.1620-1-shiju.jose@huawei.com> <20250106121017.1620-16-shiju.jose@huawei.com> <6793fa5351fc7_20f3294d0@dwillia2-xfh.jf.intel.com.notmuch> <637fa0190fe64594954ee4d9e012c39c@huawei.com> <679814068d4d1_2d1e294c4@dwillia2-xfh.jf.intel.com.notmuch> In-Reply-To: <679814068d4d1_2d1e294c4@dwillia2-xfh.jf.intel.com.notmuch> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.126.172.44] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: F0F5C40004 X-Stat-Signature: ci4nboz9daj6tar8xnytbpfeerfr8c8r X-Rspam-User: X-HE-Tag: 1738153693-896022 X-HE-Meta: U2FsdGVkX1+f0YUoMv0kOhRLGD9GFykXt+dR0MQ5AHdpxYyU/f91+yHHhbJBhdi16uGkdn6DdytP/eJQjXGVaOSiCuJDYLecUSkaMrCBF3G91jzeHqMXYZDSDPOLmtqohLKWL6upIdCormJB0g6azK3sGAAFnwPjhUunq7IYVytfNZXTLnD0MohZfKzDVprzwOih3gFTlc7mf6LX5S5qJ+Pr5eMSjombyVktiFa/002MkTrLkV5kPMbFBDEB+1HKnoEK9q6lFId0Rrv6M09ZE5QrKXbPNSK4Z4qo3lZyTYiltpCC1lZIRq0O1M1bx91B654BTt5IUIz+mA3684Mzj2Tu8yoyOGktYj0XTbp3Kk+aERowcSmMNBa6UZBkjIjqGfic9Lojla008o+gFIdoMNji6b3oqj5ujJDho2zD9xHpJE3LHs4e1MyEnqjf6prMU5CoEBE9E23JKoWkVmiv4DA4OEPE/1wJDMlAiOuwWkL4SZFNiu5Aj6B9++UXyieaM3Sc2ern0k+8/V1zjDqLnNol20zJXn8ldkvA4OioQjfkGli6l7AGT8BEzbWbbYjEEjL/LOU/Q8n7VbS4fEgFzgHsSxZAHnVI6PFrnYYbv0ApN7FDS5RbYA126eW7hz3thmePcI1B0QeNJVznNA9cNCZKIB3EqpEDi/Upm2whaYEyVss2S2jTVEWW87GiSScVqqqdIkW6LlAMkJGeN1viDIUW3jBNhw2bI8N0JquOCwrDilj4hVSs/vq1VmCFwNL0/kJZN65YNruXbU+YH88pRTqOKdZElyRJD8oJkwiS9RvlesIgUR4oOHLllga4rG/aQkMwVWbbFIx6iO0in8JPyF0SfB8fFbJCOCH8pLHagoiuYT2lMmn6wpj8fhz6qK/2YyeujSNS1ZiKQOK3EtuzVSHvOEBRAiF8hBI6fI6PX0l+NQjKJ71WhvXG8Rq7Y5CESqwuJQ1x2GQIMjSMjLc 0Rx9x2U/ E8/K3DvIEjFm1IhYgtFqtfy5PTZeBpXkTjPKGw3JqFyJhq6J0fhX+D1JdKvV6+U1lBmSM2VLP86SziJEMA69kQLnnbeo0zWzHD7OImt0XXWwhZMAglPAMigDYUF+eFOhqKcWFARlVUFxjJhah9m+jzyXfd8jAZF5nKzSOj0a7UcvUXQh36ilGuvl3JIrDWBrDaqSa/+aLCKvepP2zNOd6JOzDkksTqeL+B/piQuYx53EYderT+Y+cZ775/XNvCV90khN/IcSZOIigN7O5jzJy/7VeeX8jQ59en3uQk6IVbzevxOsPqMiBQyjfNGDAhvul6nIerFdtMP2jOCPiENTyalS94rLKnXsIhA3AXdUrljelYtpdT9WczCmerL1Pctz/k8Ij6rZ7l+0eAeuAXwWt2AviXkRs4+Knwn+WzwO/+9reATSPed3JZW1SdR23PHo2LyBj7CqJb2ArOZlOqkFOgo1ZyiUsggkF2JjceL77WWDCdpMEiuuA9uFrqWGrf0TomlYzN61xUv0zjDbmqSKBqbEKgPFOEAlCpgJnTHTrS75YZHjPB3uXOphliINUzmQdLsB7UnyhnVYgL1newW4gkL87BV6dMIWDHxfAvD3QDt2YsBaGaHxemb1QaaTDM0pIfT03MzWz9zNHRcr8yk7DC+19nl11ZrffzQlLvfcWMrFV9INwOL41IDqz+e1fq1DeS4UlkmRGzXVOQmuu7tCCMYEGP9gzU5q5tSTsuc7d0sW++pvp562Ixb5pLAPBfHj+UUQHjj2hejn0iCbE+fB8d82VdqkpXUytPrsNMVZ0MgIe7ctSEXzTSBYoyl371sCWy83Z1GkOyq1SMv7/5io6txeJ4Q== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: >-----Original Message----- >From: Dan Williams >Sent: 27 January 2025 23:17 >To: Shiju Jose ; Dan Williams >; linux-edac@vger.kernel.org; linux- >cxl@vger.kernel.org; linux-acpi@vger.kernel.org; linux-mm@kvack.org; linux= - >kernel@vger.kernel.org >Cc: bp@alien8.de; tony.luck@intel.com; rafael@kernel.org; lenb@kernel.org; >mchehab@kernel.org; dave@stgolabs.net; Jonathan Cameron >; dave.jiang@intel.com; >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 >; Zengtao (B) ; Roberto >Sassu ; kangkang.shen@futurewei.com; >wanghuiqiang ; Linuxarm > >Subject: RE: [PATCH v18 15/19] cxl/memfeature: Add CXL memory device patro= l >scrub control feature > >Shiju Jose wrote: >> Hi Dan, >> >> Thanks for the comments. >> >> Please find reply inline. >> >> Thanks, >> Shiju >> >-----Original Message----- >> >From: Dan Williams >> >Sent: 24 January 2025 20:39 >> >To: Shiju Jose ; linux-edac@vger.kernel.org; >> >linux- cxl@vger.kernel.org; linux-acpi@vger.kernel.org; >> >linux-mm@kvack.org; linux- kernel@vger.kernel.org >> >Cc: bp@alien8.de; tony.luck@intel.com; rafael@kernel.org; >> >lenb@kernel.org; mchehab@kernel.org; dan.j.williams@intel.com; >> >dave@stgolabs.net; Jonathan Cameron ; >> >dave.jiang@intel.com; 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 ; Zengtao (B) >> >; Roberto Sassu ; >> >kangkang.shen@futurewei.com; wanghuiqiang >; >> >Linuxarm ; Shiju Jose >> >Subject: Re: [PATCH v18 15/19] cxl/memfeature: Add CXL memory device >> >patrol scrub control feature >> > >> >shiju.jose@ wrote: >> >> From: Shiju Jose >> >> >> >> CXL spec 3.1 section 8.2.9.9.11.1 describes the device patrol scrub >> >> control feature. The device patrol scrub proactively locates and >> >> makes corrections to errors in regular cycle. >> >> >> >> Allow specifying the number of hours within which the patrol scrub >> >> must be completed, subject to minimum and maximum limits reported >> >> by the >> >device. >> >> Also allow disabling scrub allowing trade-off error rates against >> >> performance. >> >> >> >> Add support for patrol scrub control on CXL memory devices. >> >> Register with the EDAC device driver, which retrieves the scrub >> >> attribute descriptors from EDAC scrub and exposes the sysfs scrub >> >> control attributes to userspace. For example, scrub control for the >> >> CXL memory device "cxl_mem0" is exposed in >> >/sys/bus/edac/devices/cxl_mem0/scrubX/. >> >> >> >> Additionally, add support for region-based CXL memory patrol scrub >control. >> >> CXL memory regions may be interleaved across one or more CXL memory >> >> devices. For example, region-based scrub control for "cxl_region1" >> >> is exposed in /sys/bus/edac/devices/cxl_region1/scrubX/. >> >> >> >> Reviewed-by: Dave Jiang >> >> Co-developed-by: Jonathan Cameron >> >> Signed-off-by: Jonathan Cameron >> >> Signed-off-by: Shiju Jose >> >> --- >> >> Documentation/edac/scrub.rst | 66 ++++++ >> >> drivers/cxl/Kconfig | 17 ++ >> >> drivers/cxl/core/Makefile | 1 + >> >> drivers/cxl/core/memfeature.c | 392 >> >++++++++++++++++++++++++++++++++++ >> >> drivers/cxl/core/region.c | 6 + >> >> drivers/cxl/cxlmem.h | 7 + >> >> drivers/cxl/mem.c | 5 + >> >> include/cxl/features.h | 16 ++ >> >> 8 files changed, 510 insertions(+) create mode 100644 >> >> drivers/cxl/core/memfeature.c diff --git >> >> a/Documentation/edac/scrub.rst b/Documentation/edac/scrub.rst index >> >> f86645c7f0af..80e986c57885 100644 >> >> --- a/Documentation/edac/scrub.rst >> >> +++ b/Documentation/edac/scrub.rst >[..] >> > >> >What is this content-free blob of cat and echo statements? Please >> >write actual documentation with theory of operation, clarification of >> >assumptions, rationale for defaults, guidance on changing defaults... >> >> Jonathan already replied. > >I disagree that any of that is useful to include without rationale, and if= the >rationale is already somewhere else then delete the multiple lines of show= ing >how 'cat' and 'echo' work with sysfs. I will discuss with Jonathan on this how to modify.=20 > >[..] >> >> + depends on CXL_MEM >> > >> >Similar comment, and this also goes away if all of this just moves >> >into the new cxl_features driver. >> >> Agree with Jonathan told in reply. These are RAS specific features >> for CXL memory devices and thus added in memfeature.c > >Apoligies for this comment, I had meant to delete it along with some other >commentary along this theme after thinking it through. > >I am now advocating that Dave drop his cxl_features driver altogether and >mirror your approach. I.e. EDAC is registered from existing CXL drivers, a= nd >FWCTL can be registered against a cxl_memdev just like the fw_upload ABI. > >There was a concern that CXL needed a separate FWCTL driver in case >distributions wanted to have a policy against FWCTL, but given CXL already= has >CONFIG_CXL_MEM_RAW_COMMANDS at compile-time and a wide array of CXL >bus devices, a cxl_features device is an awkward fit. Ok.=20 > >[..] >> >> +static int cxl_ps_get_attrs(struct cxl_patrol_scrub_context *cxl_ps_= ctx, >> >> + struct cxl_memdev_ps_params *params) { >> >> + struct cxl_memdev *cxlmd; >> >> + u16 min_scrub_cycle =3D 0; >> >> + int i, ret; >> >> + >> >> + if (cxl_ps_ctx->cxlr) { >> >> + struct cxl_region *cxlr =3D cxl_ps_ctx->cxlr; >> >> + struct cxl_region_params *p =3D &cxlr->params; >> >> + >> >> + for (i =3D p->interleave_ways - 1; i >=3D 0; i--) { >> >> + struct cxl_endpoint_decoder *cxled =3D p->targets[i]; >> > >> >It looks like this is called directly as a callback from EDAC. Where >> >is the locking that keeps cxl_ps_ctx->cxlr valid, or p->targets content= stable? >> Jonathan already replied. > >I could not find that comment? I *think* it's ok because when the region i= s in the >probe state changes will not be made to this list, but it would be useful = to at >least have commentary to that effect. Protect against someone copying this >code in isolation and not consider the context. Sure. Will do. > >[..] >> >> + >> >> +int cxl_mem_ras_features_init(struct cxl_memdev *cxlmd, struct >> >> +cxl_region *cxlr) >> > >> >Please separate this into a memdev helper and a region helper. It is >> >silly to have two arguments to a function where one is expected to be >> >NULL at all times, and then have an if else statement inside that to >> >effectively turn it back into 2 code paths. >> > >> >If there is code to be shared amongst those, make *that* the shared hel= per. >> I added single function cxl_mem_ras_features_init() for both memdev >> and region based scrubbing to reduce code size as there were feedbacks t= ry >reduce code size. > >"Succint" and "concise" does not necessarily mean less lines. I would grea= tly >prefer a few more lines if it mines not outsourcing complexity to the call= ing >context. Readable code means I do not need to wonder >what: > > cxl_mem_ras_features_init(NULL, cxlr) > >...means. I can just read devm_cxl_region_edac_register(cxlr), and know ex= actly >what is happening without needing to lose my train of thought to go read w= hat >semantics cxl_mem_ras_features_init() is implementing. > >Note that all the other _init() calls in drivers/cxl/ (outside of module_i= nit >callbacks), are just purely init work, not object registration. Please kee= p that >local style. Sure. Will add separate functions for region based edac registration. > >> >> +{ >> >> + struct edac_dev_feature ras_features[CXL_DEV_NUM_RAS_FEATURES]; >> >> + char cxl_dev_name[CXL_DEV_NAME_LEN]; >> >> + int num_ras_features =3D 0; >> >> + u8 scrub_inst =3D 0; >> >> + int rc; >> >> + >> >> + rc =3D cxl_memdev_scrub_init(cxlmd, cxlr, >> >&ras_features[num_ras_features], >> >> + scrub_inst); >> >> + if (rc < 0) >> >> + return rc; >> >> + >> >> + scrub_inst++; >> >> + num_ras_features++; >> >> + >> >> + if (cxlr) >> >> + snprintf(cxl_dev_name, sizeof(cxl_dev_name), >> >> + "cxl_region%d", cxlr->id); >> > >> >Why not pass dev_name(&cxlr->dev) directly? >> Jonathan already replied. > >That was purely with the cxl_mem observation, cxlr can be passed directly. Will check. > >> > >> >> + else >> >> + snprintf(cxl_dev_name, sizeof(cxl_dev_name), >> >> + "%s_%s", "cxl", dev_name(&cxlmd->dev)); >> > >> >Can a "cxl" directory be created so that the raw name can be used? > >In fact we already do something similar for CONFIG_HMEM_REPORTING (i.e. >an "access%d" device to create a nameed directory of attributes) so it is = a >question for Boris if he wants to tolerate a parent "cxl" device to parent= all CXL >objects in EDAC. > >> > >> >> + >> >> + return edac_dev_register(&cxlmd->dev, cxl_dev_name, NULL, >> >> + num_ras_features, ras_features); >> > >> >I'm so confused... a few lines down in this patch we have: >> > >> > rc =3D cxl_mem_ras_features_init(NULL, cxlr); >> > >> >...so how can this call to edac_dev_register() unconditionally >> >de-reference @cxlmd? >> Thanks for spotting this. It is a bug, need to fix. > > >[..] >> >> +EXPORT_SYMBOL_NS_GPL(cxl_mem_ras_features_init, "CXL"); >> >> diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c >> >> index b98b1ccffd1c..c2be70cd87f8 100644 >> >> --- a/drivers/cxl/core/region.c >> >> +++ b/drivers/cxl/core/region.c >> >> @@ -3449,6 +3449,12 @@ static int cxl_region_probe(struct device *dev= ) >> >> p->res->start, p->res->end, cxlr, >> >> is_system_ram) > 0) >> >> return 0; >> >> + >> >> + rc =3D cxl_mem_ras_features_init(NULL, cxlr); >> >> + if (rc) >> >> + dev_warn(&cxlr->dev, "CXL RAS features init for >> >region_id=3D%d failed\n", >> >> + cxlr->id); >> > >> >There is more to RAS than EDAC memory scrub so this message is >> >misleading. It is also unnecessary because the driver continues to >> >load and the admin, if they care, will notice that the EDAC attributes = are >missing. >> This message was added for the debugging purpose in CXL driver. I will c= hange >to dev_dbg(). > >...but also stop calling this functionality with the blanket term "RAS". >It is "EDAC scrub and repair extensions to all the other RAS functionality= the CXL >subsystem handles directly", name it accordingly. Sure. Will change. Thanks, Shiju