[{"id":3686770,"web_url":"http://patchwork.ozlabs.org/comment/3686770/","msgid":"<20260505233439.B22ABC2BCB4@smtp.kernel.org>","list_archive_url":null,"date":"2026-05-05T23:34:39","subject":"Re: [PATCH v17 07/11] PCI/CXL: Add RCH support to CXL handlers","submitter":{"id":93311,"url":"http://patchwork.ozlabs.org/api/people/93311/","name":null,"email":"sashiko-bot@kernel.org"},"content":"Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:\n- [High] Uncorrectable protocol errors on RCH Downstream Ports are swallowed without triggering the intended panic, resulting in silent data corruption.\n- [High] cxl_forward_error() corrupts the RCD Endpoint's AER state and potentially BAR0 by misapplying the RCEC's AER Correctable Status mask.\n- [High] Forwarding RCH protocol errors to the asynchronous CXL kfifo introduces a race condition with PCIe AER recovery, leading to concurrent MMIO accesses during device reset.\n- [High] Direct uncorrectable CXL protocol errors from RCDs (RC_END) bypass the unified AER-CXL kfifo error flow and fail to panic as intended.\n--\n\ncommit 71e85613fcf97cc6374754fbf172de84d9fe7371\nAuthor: Terry Bowman \n\nPCI/CXL: Add RCH support to CXL handlers\n\nThis commit folds Restricted CXL Host (RCH) error handling into the new CXL\nPort error handling flow. RCH protocol errors are now forwarded through the\nAER-CXL kfifo, and uncorrectable errors are intended to panic via\ncxl_do_recovery().\n\n> Behavior change: an RCD uncorrectable CXL RAS error now panics via\n> cxl_do_recovery(). Before this patch the RCH path returned\n> PCI_ERS_RESULT_NEED_RESET via cxl_pci's err_handler. After this patch\n> the same condition panics.\n\nDo direct uncorrectable CXL protocol errors from RCDs (RC_END) bypass the\nunified AER-CXL kfifo error flow and fail to panic as intended?\n\nWhen an RCD (PCI_EXP_TYPE_RC_END) signals an error directly,\nhandle_error_source() invokes is_cxl_error(dev, info). However,\nis_cxl_error() checks the PCIe type but only matches PCI_EXP_TYPE_ENDPOINT,\ncompletely omitting PCI_EXP_TYPE_RC_END.\n\nConsequently, is_cxl_error() returns false, bypassing cxl_forward_error()\nand the kfifo. The error falls back to pci_aer_handle_error(), which\ntriggers the legacy cxl_error_detected() handler.\n\nThe legacy handler returns PCI_ERS_RESULT_NEED_RESET rather than triggering\ncxl_do_recovery() to panic, violating the stated safety policy for fatal\ncachemem errors.\n\n> diff --git a/drivers/cxl/core/ras.c b/drivers/cxl/core/ras.c\n> index 0a552d5a236e7..1f1dd20623f6d 100644\n> --- a/drivers/cxl/core/ras.c\n> +++ b/drivers/cxl/core/ras.c\n[ ... ]\n> @@ -329,6 +324,15 @@ EXPORT_SYMBOL_NS_GPL(cxl_error_detected, \"CXL\");\n> static void cxl_handle_proto_error(struct pci_dev *pdev, struct cxl_port *port,\n> \t\t\t\t struct cxl_dport *dport, int severity)\n> {\n> +\t/*\n> +\t * An RC_END device is an RCD (Restricted CXL Device). Its AER\n> +\t * interrupt is shared with the RCH Downstream Port, so handle RCH\n> +\t * Downstream Port protocol errors first before processing the RCD's\n> +\t * own errors. See CXL spec r3.1 s12.2.\n> +\t */\n> +\tif (pci_pcie_type(pdev) == PCI_EXP_TYPE_RC_END)\n> +\t\tcxl_handle_rdport_errors(pdev);\n> +\n\nAre uncorrectable protocol errors on RCH Downstream Ports swallowed here\nwithout triggering the intended panic?\n\ncxl_handle_rdport_errors() correctly logs the error via cxl_handle_ras(),\nwhich returns true for uncorrectable errors, but the return value is ignored.\nExecution then proceeds unconditionally to cxl_do_recovery():\n\ncxl_handle_proto_error() {\n ...\n if (pci_pcie_type(pdev) == PCI_EXP_TYPE_RC_END)\n cxl_handle_rdport_errors(pdev);\n \n if (severity == AER_CORRECTABLE) {\n ...\n } else {\n cxl_do_recovery(pdev, port, dport);\n }\n}\n\nBecause dport evaluates to NULL for RCDs in this context, cxl_do_recovery()\nchecks only the RCD Endpoint's RAS capability. If the uncorrectable error\noccurred exclusively in the RCH Downstream Port, cxl_do_recovery() observes\nthe uncorrectable error flag as false and silently returns without panicking.\n\nCould this allow the system to continue using corrupted CXL.cachemem traffic?\n\n> diff --git a/drivers/pci/pcie/aer_cxl_rch.c b/drivers/pci/pcie/aer_cxl_rch.c\n> index e471eefec9c40..83142eac0cabf 100644\n> --- a/drivers/pci/pcie/aer_cxl_rch.c\n> +++ b/drivers/pci/pcie/aer_cxl_rch.c\n[ ... ]\n> @@ -37,26 +37,11 @@ static bool cxl_error_is_native(struct pci_dev *dev)\n> static int cxl_rch_handle_error_iter(struct pci_dev *dev, void *data)\n> {\n> \tstruct aer_err_info *info = (struct aer_err_info *)data;\n> \n> \tif (!is_cxl_mem_dev(dev) || !cxl_error_is_native(dev))\n> \t\treturn 0;\n> \n> -\tguard(device)(&dev->dev);\n> -\n> -\terr_handler = dev->driver ? dev->driver->err_handler : NULL;\n> -\tif (!err_handler)\n> -\t\treturn 0;\n> -\n> -\tif (info->severity == AER_CORRECTABLE) {\n> -\t\tif (err_handler->cor_error_detected)\n> -\t\t\terr_handler->cor_error_detected(dev);\n> -\t} else if (err_handler->error_detected) {\n> -\t\tif (info->severity == AER_NONFATAL)\n> -\t\t\terr_handler->error_detected(dev, pci_channel_io_normal);\n> -\t\telse if (info->severity == AER_FATAL)\n> -\t\t\terr_handler->error_detected(dev, pci_channel_io_frozen);\n> -\t}\n> +\tcxl_forward_error(dev, info);\n> \treturn 0;\n> }\n\nDoes cxl_forward_error() corrupt the RCD Endpoint's AER state and potentially\nBAR0 by misapplying the RCEC's AER Correctable Status mask?\n\nWhen an RCH Downstream Port signals an error, it is logged as an internal\nerror by the RCEC. This code iterates over the associated RCD Endpoints and\npasses the RCD device (dev) along with the RCEC's error record (info) to\ncxl_forward_error().\n\nFor correctable errors, cxl_forward_error() executes:\n\n pci_write_config_dword(pdev, pdev->aer_cap + PCI_ERR_COR_STATUS, info->status);\n\nThis writes the RCEC's error bitmask into the RCD's Write-1-to-Clear (W1C)\nAER capability register, which will silently clear unrelated pending\ncorrectable errors on the RCD.\n\nAdditionally, if the RCD lacks a native PCIe AER capability (pdev->aer_cap\nis 0), the write targets offset 0x10 (BAR0), which might silently corrupt the\ndevice's MMIO configuration.\n\n\nDoes forwarding RCH protocol errors to the asynchronous CXL kfifo introduce a\nrace condition with PCIe AER recovery?\n\nBefore this patch, cxl_rch_handle_error_iter() synchronously called the RCD\ndriver's error handler before the AER driver proceeded with recovery. This\npatch delegates the handling to cxl_forward_error(), which queues a work item\nand returns immediately.\n\nBecause is_cxl_error() evaluates to false for the RCEC (PCI_EXP_TYPE_RC_EC),\nthe AER driver proceeds directly to pci_aer_handle_error(), invoking\npcie_do_recovery() and issuing resets.\n\nConcurrently, the asynchronous work queues wake up and access the RCH\nDownstream Port's AER and RAS MMIO capabilities. Accessing MMIO regions while\nthe device or its parent is actively undergoing reset can trigger Master\nAborts, return ~0 data, or freeze the system.","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=Hdi1yPVU;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c04:e001:36c::12fc:5321; helo=tor.lore.kernel.org;\n envelope-from=linux-pci+bounces-53814-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=\"Hdi1yPVU\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from tor.lore.kernel.org (tor.lore.kernel.org\n [IPv6:2600:3c04:e001:36c::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g9FGs4Ccpz1yJq\n\tfor ; Wed, 06 May 2026 09:34:45 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby tor.lore.kernel.org (Postfix) with ESMTP id E1D6330099B7\n\tfor ; Tue, 5 May 2026 23:34:42 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 5770F31F9A8;\n\tTue, 5 May 2026 23:34:40 +0000 (UTC)","from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org\n [10.30.226.201])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 34C4B2F745E\n\tfor ; Tue, 5 May 2026 23:34:39 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id B22ABC2BCB4;\n\tTue, 5 May 2026 23:34:39 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1778024080; cv=none;\n b=bXpf8p86GrSsPa1ouLcTBvSKBxkzsHF5MiBF4fur9yEFQ0iy4YB8opLsvnH9SQfJzL8eweCvkaKs4pkhxj2me3dKMJVoUH6bZSym9rtRwNUyzVIzikdiCICQMQOIEHVICyiQoWuAoC9Goh3ah+JVFqt1/VZkQHecGvjC3okFNrA=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1778024080; c=relaxed/simple;\n\tbh=RtlSpmKfd1Hwh1b0C6s4LGQ86riFzHAxJtEJp5s18rk=;\n\th=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date:\n\t Message-Id;\n b=rXzVYj5qSCDi0GZG9A+zP20n9EJt5wYIRoNZRcGAxUf6BGAvVbuoMAXdEbkOE3eyFko5AKVc9Saa5oIwqBOD5tmnQVHlLes7Xns/1esfC77d8M+tLEEnTizbEOmLk7G19GJ4wpYXQ2shYYwzO0pVS8C/jXwejuyzH2iVTdWRajU=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=Hdi1yPVU; arc=none smtp.client-ip=10.30.226.201","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1778024079;\n\tbh=RtlSpmKfd1Hwh1b0C6s4LGQ86riFzHAxJtEJp5s18rk=;\n\th=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date:From;\n\tb=Hdi1yPVUIb8F4FKc2as7fwB+qzPwQ5x7igdTGCHWMbMQS4BxxzooTfohtE90AraZA\n\t Bh8uajEZXAaySvzar9ykR6h8iQJxG12kuZUaWns7MH3Hwn4MwME1zICy6AvKjTI7Vv\n\t hMw2gZg3Ds5xEoRE8HB5jrIZqj1wezA0r0VxW7QAPuIk2z+REy2kQKfQDHoIvjcUNk\n\t 4vpMOAA7dxnD/uxEjwiN3uU4VwPWh1tmXkvn6fRukSLvaV0XTDD5yFkyxHJNYUy/5g\n\t 6lnLKBY9Es5D1AfVcdZdlQ2NQmDEYokTa9gZZ7raOEh0/8dnmUL3Ynz/sYdaUvvPUl\n\t bZyRW33JAfSnQ==","From":"sashiko-bot@kernel.org","Subject":"Re: [PATCH v17 07/11] PCI/CXL: Add RCH support to CXL handlers","Reply-To":"sashiko@lists.linux.dev","To":"\"Terry Bowman\" ","Cc":"linux-pci@vger.kernel.org","In-Reply-To":"<20260505173029.2718246-8-terry.bowman@amd.com>","References":"<20260505173029.2718246-8-terry.bowman@amd.com>","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"quoted-printable","Date":"Tue, 05 May 2026 23:34:39 +0000","Message-Id":"<20260505233439.B22ABC2BCB4@smtp.kernel.org>","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":""}},{"id":3686777,"web_url":"http://patchwork.ozlabs.org/comment/3686777/","msgid":"","list_archive_url":null,"date":"2026-05-05T23:59:58","subject":"Re: [PATCH v17 07/11] PCI/CXL: Add RCH support to CXL handlers","submitter":{"id":13225,"url":"http://patchwork.ozlabs.org/api/people/13225/","name":"Dave Jiang","email":"dave.jiang@intel.com"},"content":"On 5/5/26 10:30 AM, Terry Bowman wrote:\n> Restricted CXL Host (RCH) error handling is a separate path from the\n> new CXL Port error handling flow. Fold RCH error handling into the\n> Port flow so both share a common entry point.\n> \n> Update cxl_rch_handle_error_iter() to forward RCH protocol errors\n> through the AER-CXL kfifo.\n> \n> Update cxl_handle_proto_error() to dispatch RCH errors via\n> cxl_handle_rdport_errors(). cxl_handle_rdport_errors() handles both\n> correctable and uncorrectable RCH protocol errors.\n> \n> Behavior change: an RCD uncorrectable CXL RAS error now panics via\n> cxl_do_recovery(). Before this patch the RCH path returned\n> PCI_ERS_RESULT_NEED_RESET via cxl_pci's err_handler. After this patch\n> the same condition panics. This matches the panic policy added in the\n> common CXL Port protocol error flow. CXL.cachemem traffic cannot be\n> safely recovered from an uncorrectable protocol error in software.\n> \n> Change cxl_handle_rdport_errors() to take a PCI device instead of a\n> CXL device state, matching the new caller context. The error trace events\n> emitted from this path now report device= instead of device=,\n> matching the rest of the unified CXL trace events. Userspace consumers keyed\n> off the memdev name need to map the PCI BDF back to a memdev.\n> \n> Include the RCD Endpoint serial number in RCH log messages so the RCH\n> can be associated with its RCD.\n> \n> Remove the cxlds->rcd check from cxl_cor_error_detected() and\n> cxl_error_detected(). RCH errors are now forwarded by\n> cxl_rch_handle_error_iter() through the AER-CXL kfifo to\n> cxl_handle_proto_error(), so cxl_pci's err_handler no longer sees\n> them.\n> \n> Signed-off-by: Terry Bowman \n> \n> ---\n> \n> Changes in v16->v17:\n> - Drop now-dead cxlds->rcd branches from cxl_{cor_,}error_detected().\n> - Drop duplicate subject line from commit body.\n> - Document panic-on-uncorrectable behavior change for RCD path.\n> - Document trace event device-name change (memN -> PCI BDF) for RCH path.\n> - Rewrite cxl_handle_proto_error() RC_END comment to clarify RCD/RCH shared\n> interrupt relationship\n> - Rewrite commit message\n> \n> Changes in v16:\n> - New commit\n> ---\n> drivers/cxl/core/core.h | 4 ++--\n> drivers/cxl/core/ras.c | 14 +++++++++-----\n> drivers/cxl/core/ras_rch.c | 8 +++-----\n> drivers/pci/pcie/aer_cxl_rch.c | 17 +----------------\n> 4 files changed, 15 insertions(+), 28 deletions(-)\n> \n> diff --git a/drivers/cxl/core/core.h b/drivers/cxl/core/core.h\n> index bc36cd1575a4..2c7387506dfb 100644\n> --- a/drivers/cxl/core/core.h\n> +++ b/drivers/cxl/core/core.h\n> @@ -188,7 +188,7 @@ void cxl_handle_cor_ras(struct device *dev, u64 serial,\n> \t\t\tvoid __iomem *ras_base);\n> void cxl_dport_map_rch_aer(struct cxl_dport *dport);\n> void cxl_disable_rch_root_ints(struct cxl_dport *dport);\n> -void cxl_handle_rdport_errors(struct cxl_dev_state *cxlds);\n> +void cxl_handle_rdport_errors(struct pci_dev *pdev);\n> void devm_cxl_dport_ras_setup(struct cxl_dport *dport);\n> #else\n> static inline int cxl_ras_init(void)\n> @@ -205,7 +205,7 @@ static inline void cxl_handle_cor_ras(struct device *dev, u64 serial,\n> \t\t\t\t void __iomem *ras_base) { }\n> static inline void cxl_dport_map_rch_aer(struct cxl_dport *dport) { }\n> static inline void cxl_disable_rch_root_ints(struct cxl_dport *dport) { }\n> -static inline void cxl_handle_rdport_errors(struct cxl_dev_state *cxlds) { }\n> +static inline void cxl_handle_rdport_errors(struct pci_dev *pdev) { }\n> static inline void devm_cxl_dport_ras_setup(struct cxl_dport *dport) { }\n> #endif /* CONFIG_CXL_RAS */\n> \n> diff --git a/drivers/cxl/core/ras.c b/drivers/cxl/core/ras.c\n> index 0a552d5a236e..1f1dd20623f6 100644\n> --- a/drivers/cxl/core/ras.c\n> +++ b/drivers/cxl/core/ras.c\n> @@ -267,9 +267,6 @@ void cxl_cor_error_detected(struct pci_dev *pdev)\n> \t\t\treturn;\n> \t\t}\n> \n> -\t\tif (cxlds->rcd)\n> -\t\t\tcxl_handle_rdport_errors(cxlds);\n> -\n> \t\tcxl_handle_cor_ras(&cxlds->cxlmd->dev, pci_get_dsn(pdev),\n> \t\t\t\t cxlmd->endpoint->regs.ras);\n> \t}\n> @@ -292,8 +289,6 @@ pci_ers_result_t cxl_error_detected(struct pci_dev *pdev,\n> \t\t\treturn PCI_ERS_RESULT_DISCONNECT;\n> \t\t}\n> \n> -\t\tif (cxlds->rcd)\n> -\t\t\tcxl_handle_rdport_errors(cxlds);\n> \t\t/*\n> \t\t * A frozen channel indicates an impending reset which is fatal to\n> \t\t * CXL.mem operation, and will likely crash the system. On the off\n> @@ -329,6 +324,15 @@ EXPORT_SYMBOL_NS_GPL(cxl_error_detected, \"CXL\");\n> static void cxl_handle_proto_error(struct pci_dev *pdev, struct cxl_port *port,\n> \t\t\t\t struct cxl_dport *dport, int severity)\n> {\n> +\t/*\n> +\t * An RC_END device is an RCD (Restricted CXL Device). Its AER\n> +\t * interrupt is shared with the RCH Downstream Port, so handle RCH\n> +\t * Downstream Port protocol errors first before processing the RCD's\n> +\t * own errors. See CXL spec r3.1 s12.2.\n> +\t */\n> +\tif (pci_pcie_type(pdev) == PCI_EXP_TYPE_RC_END)\n\nMay as well use is_cxl_restricted(pdev).\n\nDJ\n \n> +\t\tcxl_handle_rdport_errors(pdev);\n> +\n> \tif (severity == AER_CORRECTABLE) {\n> \t\tcxl_handle_cor_ras(&pdev->dev, pci_get_dsn(pdev),\n> \t\t\t\t to_ras_base(port, dport));\n> diff --git a/drivers/cxl/core/ras_rch.c b/drivers/cxl/core/ras_rch.c\n> index 61835fbafc0f..cbd02cabefbc 100644\n> --- a/drivers/cxl/core/ras_rch.c\n> +++ b/drivers/cxl/core/ras_rch.c\n> @@ -1,7 +1,6 @@\n> // SPDX-License-Identifier: GPL-2.0-only\n> /* Copyright(c) 2025 AMD Corporation. All rights reserved. */\n> \n> -#include \n> #include \n> #include \"cxl.h\"\n> #include \"core.h\"\n> @@ -95,9 +94,8 @@ static bool cxl_rch_get_aer_severity(struct aer_capability_regs *aer_regs,\n> \treturn false;\n> }\n> \n> -void cxl_handle_rdport_errors(struct cxl_dev_state *cxlds)\n> +void cxl_handle_rdport_errors(struct pci_dev *pdev)\n> {\n> -\tstruct pci_dev *pdev = to_pci_dev(cxlds->dev);\n> \tstruct aer_capability_regs aer_regs;\n> \tstruct cxl_dport *dport;\n> \tint severity;\n> @@ -115,9 +113,9 @@ void cxl_handle_rdport_errors(struct cxl_dev_state *cxlds)\n> \n> \tpci_print_aer(pdev, severity, &aer_regs);\n> \tif (severity == AER_CORRECTABLE)\n> -\t\tcxl_handle_cor_ras(&cxlds->cxlmd->dev, pci_get_dsn(pdev),\n> +\t\tcxl_handle_cor_ras(&pdev->dev, pci_get_dsn(pdev),\n> \t\t\t\t dport->regs.ras);\n> \telse\n> -\t\tcxl_handle_ras(&cxlds->cxlmd->dev, pci_get_dsn(pdev),\n> +\t\tcxl_handle_ras(&pdev->dev, pci_get_dsn(pdev),\n> \t\t\t dport->regs.ras);\n> }\n> diff --git a/drivers/pci/pcie/aer_cxl_rch.c b/drivers/pci/pcie/aer_cxl_rch.c\n> index e471eefec9c4..83142eac0cab 100644\n> --- a/drivers/pci/pcie/aer_cxl_rch.c\n> +++ b/drivers/pci/pcie/aer_cxl_rch.c\n> @@ -37,26 +37,11 @@ static bool cxl_error_is_native(struct pci_dev *dev)\n> static int cxl_rch_handle_error_iter(struct pci_dev *dev, void *data)\n> {\n> \tstruct aer_err_info *info = (struct aer_err_info *)data;\n> -\tconst struct pci_error_handlers *err_handler;\n> \n> \tif (!is_cxl_mem_dev(dev) || !cxl_error_is_native(dev))\n> \t\treturn 0;\n> \n> -\tguard(device)(&dev->dev);\n> -\n> -\terr_handler = dev->driver ? dev->driver->err_handler : NULL;\n> -\tif (!err_handler)\n> -\t\treturn 0;\n> -\n> -\tif (info->severity == AER_CORRECTABLE) {\n> -\t\tif (err_handler->cor_error_detected)\n> -\t\t\terr_handler->cor_error_detected(dev);\n> -\t} else if (err_handler->error_detected) {\n> -\t\tif (info->severity == AER_NONFATAL)\n> -\t\t\terr_handler->error_detected(dev, pci_channel_io_normal);\n> -\t\telse if (info->severity == AER_FATAL)\n> -\t\t\terr_handler->error_detected(dev, pci_channel_io_frozen);\n> -\t}\n> +\tcxl_forward_error(dev, info);\n> \treturn 0;\n> }\n>","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256\n header.s=Intel header.b=QL1ttLtH;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c09:e001:a7::12fc:5321; helo=sto.lore.kernel.org;\n envelope-from=linux-pci+bounces-53819-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com\n header.b=\"QL1ttLtH\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=198.175.65.17","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=intel.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=intel.com"],"Received":["from sto.lore.kernel.org (sto.lore.kernel.org\n [IPv6:2600:3c09:e001:a7::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g9FrP0RKdz1yJq\n\tfor ; Wed, 06 May 2026 10:00:21 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sto.lore.kernel.org (Postfix) with ESMTP id 9E4FD30208B6\n\tfor ; Wed, 6 May 2026 00:00:17 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id E65BB32E6BD;\n\tWed, 6 May 2026 00:00:14 +0000 (UTC)","from mgamail.intel.com (mgamail.intel.com [198.175.65.17])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 4308333A9C3;\n\tWed, 6 May 2026 00:00:12 +0000 (UTC)","from fmviesa003.fm.intel.com ([10.60.135.143])\n by orvoesa109.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 05 May 2026 17:00:05 -0700","from spandruv-mobl5.amr.corp.intel.com (HELO [10.125.110.85])\n ([10.125.110.85])\n by fmviesa003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 05 May 2026 17:00:01 -0700"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1778025614; cv=none;\n b=RhxpgQAqn5g8C3TCC+RsB44lu5fw2kNE27OKrVoMgFm8Ms/k29ALQ08of2qi8S5yKwaEVzkC+7pbEyBmg4fJKqFHbBemFPy0pqPvy1PnZYxxMgWfJdY01Y0KBg1ZaekQMzjhqNK/aEHaJ8/WYRk/3SI80PgHAIDdDjcpnUxX8hs=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1778025614; c=relaxed/simple;\n\tbh=BU+ku2HbqivXM3GBbrgS1jHksjPhIuqY0hTbeAtLpCY=;\n\th=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:\n\t In-Reply-To:Content-Type;\n b=k2vWaspMBStlE8G3npRWZryKw8j+tHFs9wmdcElRDrUgd5RKIqcFLS9/v0VqdJtuai6+2osmkwy1r0GY4/RNJrhedDxHAqyvPJixNgfB9husYkWkIT9UaIdrVKc9G5rry62ooQNEHaSJJQz9NzgTZ6NiX7IO0WDPmhVS3y7GhhA=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=intel.com;\n spf=pass smtp.mailfrom=intel.com;\n dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com\n header.b=QL1ttLtH; arc=none smtp.client-ip=198.175.65.17","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n d=intel.com; i=@intel.com; q=dns/txt; s=Intel;\n t=1778025613; x=1809561613;\n h=message-id:date:mime-version:subject:to:cc:references:\n from:in-reply-to:content-transfer-encoding;\n bh=BU+ku2HbqivXM3GBbrgS1jHksjPhIuqY0hTbeAtLpCY=;\n b=QL1ttLtHqu2a9nn3xs8IQg763XleAATfO1eA5icokypFDhoSvWBa+q6r\n hfICvgYrAU/todikd69+Y20zF+mO3Sg/bkY9BRb25EAtRc3tmvkmvsgUj\n cxlLI+mUu2Datc9HCs6gOuaLVO2v8eIMaiAt6WkrzPQWdH+GgGhNdyN6h\n CX0IDB4cRaY3sCOFxt5GUmJ2QZLpFY3DyF7qF6c0sdI9VsauUAdD2XcZ3\n yH6AG375812AxoZQaOzn+4kIgv2ldnTiMv9OD/sMhFG0rEpJEmvJD23D1\n smsAjJhU1dbLP0jA+vWRRSRHTMF7PapOzNnxDOme4pPQHE4HwmcDi71t5\n Q==;","X-CSE-ConnectionGUID":["mwwx3kN2QWuEYuxkRYhbog==","97GRI57NQquqI9I39KH9Dw=="],"X-CSE-MsgGUID":["Jcj8HCLWRWmfuIMRvYuWXw==","MkPu+dmIQtm9R5fI4JCdNg=="],"X-IronPort-AV":["E=McAfee;i=\"6800,10657,11777\"; a=\"78904501\"","E=Sophos;i=\"6.23,218,1770624000\";\n d=\"scan'208\";a=\"78904501\""],"X-ExtLoop1":"1","Message-ID":"","Date":"Tue, 5 May 2026 16:59:58 -0700","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH v17 07/11] PCI/CXL: Add RCH support to CXL handlers","To":"Terry Bowman , dave@stgolabs.net, jic23@kernel.org,\n alison.schofield@intel.com, djbw@kernel.org, bhelgaas@google.com,\n shiju.jose@huawei.com, ming.li@zohomail.com,\n Smita.KoralahalliChannabasappa@amd.com, rrichter@amd.com,\n dan.carpenter@linaro.org, PradeepVineshReddy.Kodamati@amd.com,\n lukas@wunner.de, Benjamin.Cheatham@amd.com,\n sathyanarayanan.kuppuswamy@linux.intel.com, vishal.l.verma@intel.com,\n alucerop@amd.com, ira.weiny@intel.com, corbet@lwn.net, rafael@kernel.org,\n xueshuai@linux.alibaba.com, linux-cxl@vger.kernel.org","Cc":"linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,\n linux-acpi@vger.kernel.org, linux-doc@vger.kernel.org","References":"<20260505173029.2718246-1-terry.bowman@amd.com>\n <20260505173029.2718246-8-terry.bowman@amd.com>","Content-Language":"en-US","From":"Dave Jiang ","In-Reply-To":"<20260505173029.2718246-8-terry.bowman@amd.com>","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"7bit"}}]