[{"id":3688152,"web_url":"http://patchwork.ozlabs.org/comment/3688152/","msgid":"<20260508041956.C8F10C2BCB0@smtp.kernel.org>","list_archive_url":null,"date":"2026-05-08T04:19:56","subject":"Re: [PATCH v4 2/2] PCI: cadence: Add debugfs property to provide\n LTSSM status of the PCIe link","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 5 potential issue(s) to consider:\n- [High] PCIE_CADENCE_DEBUGFS tristate configuration causes build failure and module linkage issues.\n- [High] Race condition in debugfs deinitialization leads to unprotected hardware access.\n- [High] Missing Runtime PM reference in debugfs read handler causes system crash.\n- [Medium] Missing link teardown in `cdns_pcie_hpa_host_disable`.\n- [Medium] Incorrect bitmask `CDNS_PCIE_LGA_LTSSM_STATUS_MASK` truncates LTSSM states.\n--\n\ncommit b032928b3c42715d7bb97e0bd26a99d252cd98d9\nAuthor: Hans Zhang <18255117159@163.com>\n\nPCI: cadence: Add debugfs property to provide LTSSM status of the PCIe link\n\nAdd the debugfs property to provide a view of the current link's LTSSM\nstatus from the Root Port device.\n\n> diff --git a/drivers/pci/controller/cadence/Kconfig b/drivers/pci/controller/cadence/Kconfig\n> index 9e651d5459735..cb010bc97aad3 100644\n> --- a/drivers/pci/controller/cadence/Kconfig\n> +++ b/drivers/pci/controller/cadence/Kconfig\n> @@ -6,6 +6,15 @@ menu \"Cadence-based PCIe controllers\"\n>  config PCIE_CADENCE\n>  \ttristate\n>  \n> +config PCIE_CADENCE_DEBUGFS\n> +\ttristate \"Cadence PCIe debugfs entries\"\n\nCould this Kconfig option be changed to a bool?\n\nWhen configured as a module (=m), Kbuild defines\nCONFIG_PCIE_CADENCE_DEBUGFS_MODULE, not CONFIG_PCIE_CADENCE_DEBUGFS. As a\nresult, the preprocessor check in pcie-cadence.h evaluates to false, causing\nthe header to declare empty static inline stubs. When pcie-cadence-debugfs.c\ndefines the non-static versions, the build fails with a function redefinition\nerror.\n\nFurthermore, changing the check to IS_ENABLED(CONFIG_PCIE_CADENCE_DEBUGFS)\nwould cause linkage errors if the core drivers are built-in while the debugfs\nfeature is a module, since built-in code cannot call module functions.\n\n[ ... ]\n\n> diff --git a/drivers/pci/controller/cadence/pcie-cadence-debugfs.c b/drivers/pci/controller/cadence/pcie-cadence-debugfs.c\n> new file mode 100644\n> index 0000000000000..a4f0c4f6f98f4\n> --- /dev/null\n> +++ b/drivers/pci/controller/cadence/pcie-cadence-debugfs.c\n> @@ -0,0 +1,208 @@\n[ ... ]\n> +#define CDNS_PCIE_LGA_LTSSM_STATUS_MASK\tGENMASK(29, 24)\n\nDoes this mask need to be extended to cover all possible states?\n\nThis mask covers only 6 bits, allowing it to extract values up to 63.\nHowever, the cdns_pcie_ltssm enum defines states up to 127. If the\nhardware enters a state 64 or higher, FIELD_GET will silently truncate\nthe value, making state 65 appear as state 1.\n\n[ ... ]\n> +static int ltssm_status_show(struct seq_file *s, void *v)\n> +{\n> +\tstruct cdns_pcie *pci = s->private;\n> +\tenum cdns_pcie_ltssm ltssm;\n> +\tu32 reg;\n> +\n> +\tif (pci->is_hpa) {\n> +\t\treg = cdns_pcie_hpa_readl(pci, REG_BANK_IP_REG,\n> +\t\t\t\t\tCDNS_PCIE_HPA_PHY_DBG_STS_REG0);\n> +\t\tltssm = FIELD_GET(CDNS_PCIE_HPA_LTSSM_STATUS_MASK, reg);\n> +\t} else {\n> +\t\treg = cdns_pcie_readl(pci, CDNS_PCIE_LM_BASE);\n> +\t\tltssm = FIELD_GET(CDNS_PCIE_LGA_LTSSM_STATUS_MASK, reg);\n> +\t}\n\nIs a runtime PM reference required here before accessing the hardware?\n\nSince the driver supports power management, the controller might be in a\nlow-power, clock-gated state when this debugfs file is read. Reading the\nregisters without calling pm_runtime_get_sync() first could cause a bus fault\nand crash the system.\n\n[ ... ]\n\n> diff --git a/drivers/pci/controller/cadence/pcie-cadence-ep.c b/drivers/pci/controller/cadence/pcie-cadence-ep.c\n> index c0e1194a936b3..38a0157b60dc7 100644\n> --- a/drivers/pci/controller/cadence/pcie-cadence-ep.c\n> +++ b/drivers/pci/controller/cadence/pcie-cadence-ep.c\n> @@ -659,6 +659,7 @@ void cdns_pcie_ep_disable(struct cdns_pcie_ep *ep)\n>  \tpci_epc_mem_free_addr(epc, ep->irq_phys_addr, ep->irq_cpu_addr,\n>  \t\t\t      SZ_128K);\n>  \tpci_epc_mem_exit(epc);\n> +\tcdns_pcie_debugfs_deinit(&ep->pcie);\n>  }\n\nShould cdns_pcie_debugfs_deinit() be called earlier in the teardown process?\n\nIf a userspace process is currently reading the debugfs file while the module\nis being removed, ltssm_status_show() could attempt to read registers after\nthe hardware has been deactivated, potentially resulting in a bus fault.\nRemoving the debugfs entries first ensures no new reads can begin while the\nhardware is shut down.\n\n[ ... ]\n\n> diff --git a/drivers/pci/controller/cadence/pcie-cadence-host-hpa.c b/drivers/pci/controller/cadence/pcie-cadence-host-hpa.c\n> index 0f540bed58e88..8bf7cc106413b 100644\n> --- a/drivers/pci/controller/cadence/pcie-cadence-host-hpa.c\n> +++ b/drivers/pci/controller/cadence/pcie-cadence-host-hpa.c\n> @@ -309,6 +309,18 @@ int cdns_pcie_hpa_host_link_setup(struct cdns_pcie_rc *rc)\n>  }\n>  EXPORT_SYMBOL_GPL(cdns_pcie_hpa_host_link_setup);\n>  \n> +void cdns_pcie_hpa_host_disable(struct cdns_pcie_rc *rc)\n> +{\n> +\tstruct pci_host_bridge *bridge;\n> +\n> +\tbridge = pci_host_bridge_from_priv(rc);\n> +\tpci_stop_root_bus(bridge->bus);\n> +\tpci_remove_root_bus(bridge->bus);\n> +\n\nIs it necessary to stop the PCIe link here?\n\nThe setup path explicitly starts the link with cdns_pcie_start_link(),\nbut this teardown function omits stopping it or disabling PTM responses.\nLeaving the link active after the bus is unregistered could lead to\nspurious interrupts or unhandled DMA requests.\n\n> +\tcdns_pcie_debugfs_deinit(&rc->pcie);\n\nSimilar to the endpoint path, should debugfs teardown happen before\nthe hardware is disabled to avoid concurrent access faults?\n\n> +}\n\n[ ... ]\n\n> diff --git a/drivers/pci/controller/cadence/pcie-cadence-host.c b/drivers/pci/controller/cadence/pcie-cadence-host.c\n> index 0bc9e6e90e0e0..873d496c440f0 100644\n> --- a/drivers/pci/controller/cadence/pcie-cadence-host.c\n> +++ b/drivers/pci/controller/cadence/pcie-cadence-host.c\n> @@ -370,6 +370,7 @@ void cdns_pcie_host_disable(struct cdns_pcie_rc *rc)\n>  \n>  \tcdns_pcie_host_deinit(rc);\n>  \tcdns_pcie_host_link_disable(rc);\n> +\tcdns_pcie_debugfs_deinit(&rc->pcie);\n>  }\n\nShould this debugfs teardown be moved to the beginning of the function\nfor the same reason mentioned above?","headers":{"Return-Path":"\n <linux-pci+bounces-54189-incoming=patchwork.ozlabs.org@vger.kernel.org>","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=UvBvBj4E;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=linux-pci+bounces-54189-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=\"UvBvBj4E\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org\n [IPv6:2600:3c0a:e001:db::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 4gBbW34CkHz1yK7\n\tfor <incoming@patchwork.ozlabs.org>; Fri, 08 May 2026 14:19:59 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 10BF5301DB8E\n\tfor <incoming@patchwork.ozlabs.org>; Fri,  8 May 2026 04:19:58 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 69D9A2DEA8F;\n\tFri,  8 May 2026 04:19:57 +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 46968274FDF\n\tfor <linux-pci@vger.kernel.org>; Fri,  8 May 2026 04:19:57 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id C8F10C2BCB0;\n\tFri,  8 May 2026 04:19:56 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1778213997; cv=none;\n b=dceV52w5x6rSfK91wVmGogF23fq1XIKFky/9jsDxT8DXGzhFldpGogFElJlzBfViecQ69w/e04JW+a5G9JX8iFngh/3z4O8RLCvKUQ1hSCRQjtn9KDAHsJ6v76MCCcCtuFw87xYNStJkg09aM6giKyxRwmbLa+UDBaTpFTjlHHo=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1778213997; c=relaxed/simple;\n\tbh=JbQ7qR5wtIm89m6j5d05ehY7NlatOUbzq1F1UGKvDkU=;\n\th=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date:\n\t Message-Id;\n b=fRc0lw36XqCbjl1LmZE/rMK7cKO1AMuuNHoDFsWB/HqzpfIn959695kSmNWwcFuHurQIVrUgZb71JLJyYoG7L9WAzBYnDn9pL+KAhA+VBOKOzD9PXfqB3YScj14HE4pFg6TBx+SUl8F3yyE0tWiGow15dOvX1BqOU7PaIXIJ9k8=","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=UvBvBj4E; 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=1778213996;\n\tbh=JbQ7qR5wtIm89m6j5d05ehY7NlatOUbzq1F1UGKvDkU=;\n\th=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date:From;\n\tb=UvBvBj4E+wjdoJtamlQxpS2djQHkM9Es83xo+l24JqJ0o7xlktt8q1HRcL1TG755T\n\t p0uGs33PNvmrTh0ivuf3ociLMWN4Fyjh8VrIV5JNaoBp68SYj2SnwLEg58PWPDwC1V\n\t w32+Krcx1JFEhuYs3U3VaOmMNHdxVHKSAmW1bu9pzgDPJvC2rw6T9aZmoNSD7PaXgW\n\t VMpdZNQGRlfhQTPOZ7sHDiO29XbeMxqLzUXQcDuxijMQZLU6TyqptecyPijk3bTsao\n\t B73gLuZvrAzA0lGqGwVZ9NpM6wGuubLBJinxA8BBGvvdMlyXRH5e+iQo6G327stLBp\n\t YIamqP9oEARaw==","From":"sashiko-bot@kernel.org","Subject":"Re: [PATCH v4 2/2] PCI: cadence: Add debugfs property to provide\n LTSSM status of the PCIe link","Reply-To":"sashiko@lists.linux.dev","To":"\"Hans Zhang\" <18255117159@163.com>","Cc":"linux-pci@vger.kernel.org","In-Reply-To":"<20260508034101.1910036-3-18255117159@163.com>","References":"<20260508034101.1910036-3-18255117159@163.com>","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"quoted-printable","Date":"Fri, 08 May 2026 04:19:56 +0000","Message-Id":"<20260508041956.C8F10C2BCB0@smtp.kernel.org>","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"<linux-pci.vger.kernel.org>","List-Subscribe":"<mailto:linux-pci+subscribe@vger.kernel.org>","List-Unsubscribe":"<mailto:linux-pci+unsubscribe@vger.kernel.org>"}},{"id":3688156,"web_url":"http://patchwork.ozlabs.org/comment/3688156/","msgid":"<10503cf8-2f2c-4a8d-8c24-f1056859edd8@163.com>","list_archive_url":null,"date":"2026-05-08T04:31:12","subject":"Re: [PATCH v4 2/2] PCI: cadence: Add debugfs property to provide\n LTSSM status of the PCIe link","submitter":{"id":89937,"url":"http://patchwork.ozlabs.org/api/people/89937/","name":"Hans Zhang","email":"18255117159@163.com"},"content":"On 5/8/26 12:19, sashiko-bot@kernel.org wrote:\n> Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:\n> - [High] PCIE_CADENCE_DEBUGFS tristate configuration causes build failure and module linkage issues.\n> - [High] Race condition in debugfs deinitialization leads to unprotected hardware access.\n> - [High] Missing Runtime PM reference in debugfs read handler causes system crash.\n> - [Medium] Missing link teardown in `cdns_pcie_hpa_host_disable`.\n> - [Medium] Incorrect bitmask `CDNS_PCIE_LGA_LTSSM_STATUS_MASK` truncates LTSSM states.\n> --\n> \n> commit b032928b3c42715d7bb97e0bd26a99d252cd98d9\n> Author: Hans Zhang <18255117159@163.com>\n> \n> PCI: cadence: Add debugfs property to provide LTSSM status of the PCIe link\n> \n> Add the debugfs property to provide a view of the current link's LTSSM\n> status from the Root Port device.\n> \n>> diff --git a/drivers/pci/controller/cadence/Kconfig b/drivers/pci/controller/cadence/Kconfig\n>> index 9e651d5459735..cb010bc97aad3 100644\n>> --- a/drivers/pci/controller/cadence/Kconfig\n>> +++ b/drivers/pci/controller/cadence/Kconfig\n>> @@ -6,6 +6,15 @@ menu \"Cadence-based PCIe controllers\"\n>>   config PCIE_CADENCE\n>>   \ttristate\n>>   \n>> +config PCIE_CADENCE_DEBUGFS\n>> +\ttristate \"Cadence PCIe debugfs entries\"\n> \n> Could this Kconfig option be changed to a bool?\n\nThis is the reminder from Mani that I made the necessary modifications \nfor, because the Cadence PCIe driver is a support module.\n\n> \n> When configured as a module (=m), Kbuild defines\n> CONFIG_PCIE_CADENCE_DEBUGFS_MODULE, not CONFIG_PCIE_CADENCE_DEBUGFS. As a\n> result, the preprocessor check in pcie-cadence.h evaluates to false, causing\n> the header to declare empty static inline stubs. When pcie-cadence-debugfs.c\n> defines the non-static versions, the build fails with a function redefinition\n> error.\n> \n> Furthermore, changing the check to IS_ENABLED(CONFIG_PCIE_CADENCE_DEBUGFS)\n> would cause linkage errors if the core drivers are built-in while the debugfs\n> feature is a module, since built-in code cannot call module functions.\n> \n> [ ... ]\n> \n>> diff --git a/drivers/pci/controller/cadence/pcie-cadence-debugfs.c b/drivers/pci/controller/cadence/pcie-cadence-debugfs.c\n>> new file mode 100644\n>> index 0000000000000..a4f0c4f6f98f4\n>> --- /dev/null\n>> +++ b/drivers/pci/controller/cadence/pcie-cadence-debugfs.c\n>> @@ -0,0 +1,208 @@\n> [ ... ]\n>> +#define CDNS_PCIE_LGA_LTSSM_STATUS_MASK\tGENMASK(29, 24)\n> \n> Does this mask need to be extended to cover all possible states?\n> \n> This mask covers only 6 bits, allowing it to extract values up to 63.\n> However, the cdns_pcie_ltssm enum defines states up to 127. If the\n> hardware enters a state 64 or higher, FIELD_GET will silently truncate\n> the value, making state 65 appear as state 1.\n\nHi Manikandan,\n\nI have already confirmed this with Manikandan. You can ask Manikandan to \nconfirm it again.\n\n\n> \n> [ ... ]\n>> +static int ltssm_status_show(struct seq_file *s, void *v)\n>> +{\n>> +\tstruct cdns_pcie *pci = s->private;\n>> +\tenum cdns_pcie_ltssm ltssm;\n>> +\tu32 reg;\n>> +\n>> +\tif (pci->is_hpa) {\n>> +\t\treg = cdns_pcie_hpa_readl(pci, REG_BANK_IP_REG,\n>> +\t\t\t\t\tCDNS_PCIE_HPA_PHY_DBG_STS_REG0);\n>> +\t\tltssm = FIELD_GET(CDNS_PCIE_HPA_LTSSM_STATUS_MASK, reg);\n>> +\t} else {\n>> +\t\treg = cdns_pcie_readl(pci, CDNS_PCIE_LM_BASE);\n>> +\t\tltssm = FIELD_GET(CDNS_PCIE_LGA_LTSSM_STATUS_MASK, reg);\n>> +\t}\n> \n> Is a runtime PM reference required here before accessing the hardware?\n> \n> Since the driver supports power management, the controller might be in a\n> low-power, clock-gated state when this debugfs file is read. Reading the\n> registers without calling pm_runtime_get_sync() first could cause a bus fault\n> and crash the system.\n> \n> [ ... ]\n> \n>> diff --git a/drivers/pci/controller/cadence/pcie-cadence-ep.c b/drivers/pci/controller/cadence/pcie-cadence-ep.c\n>> index c0e1194a936b3..38a0157b60dc7 100644\n>> --- a/drivers/pci/controller/cadence/pcie-cadence-ep.c\n>> +++ b/drivers/pci/controller/cadence/pcie-cadence-ep.c\n>> @@ -659,6 +659,7 @@ void cdns_pcie_ep_disable(struct cdns_pcie_ep *ep)\n>>   \tpci_epc_mem_free_addr(epc, ep->irq_phys_addr, ep->irq_cpu_addr,\n>>   \t\t\t      SZ_128K);\n>>   \tpci_epc_mem_exit(epc);\n>> +\tcdns_pcie_debugfs_deinit(&ep->pcie);\n>>   }\n> \n> Should cdns_pcie_debugfs_deinit() be called earlier in the teardown process?\n\nWill change.\n\n> \n> If a userspace process is currently reading the debugfs file while the module\n> is being removed, ltssm_status_show() could attempt to read registers after\n> the hardware has been deactivated, potentially resulting in a bus fault.\n> Removing the debugfs entries first ensures no new reads can begin while the\n> hardware is shut down.\n> \n> [ ... ]\n> \n>> diff --git a/drivers/pci/controller/cadence/pcie-cadence-host-hpa.c b/drivers/pci/controller/cadence/pcie-cadence-host-hpa.c\n>> index 0f540bed58e88..8bf7cc106413b 100644\n>> --- a/drivers/pci/controller/cadence/pcie-cadence-host-hpa.c\n>> +++ b/drivers/pci/controller/cadence/pcie-cadence-host-hpa.c\n>> @@ -309,6 +309,18 @@ int cdns_pcie_hpa_host_link_setup(struct cdns_pcie_rc *rc)\n>>   }\n>>   EXPORT_SYMBOL_GPL(cdns_pcie_hpa_host_link_setup);\n>>   \n>> +void cdns_pcie_hpa_host_disable(struct cdns_pcie_rc *rc)\n>> +{\n>> +\tstruct pci_host_bridge *bridge;\n>> +\n>> +\tbridge = pci_host_bridge_from_priv(rc);\n>> +\tpci_stop_root_bus(bridge->bus);\n>> +\tpci_remove_root_bus(bridge->bus);\n>> +\n> \n> Is it necessary to stop the PCIe link here?\nThe HPA driver does not yet provide the \"stop the PCIe link\" function. \nMore will be added later.\n\n> \n> The setup path explicitly starts the link with cdns_pcie_start_link(),\n> but this teardown function omits stopping it or disabling PTM responses.\n> Leaving the link active after the bus is unregistered could lead to\n> spurious interrupts or unhandled DMA requests.\n> \n>> +\tcdns_pcie_debugfs_deinit(&rc->pcie);\n> \n> Similar to the endpoint path, should debugfs teardown happen before\n> the hardware is disabled to avoid concurrent access faults?\n\nWill change.\n\n> \n>> +}\n> \n> [ ... ]\n> \n>> diff --git a/drivers/pci/controller/cadence/pcie-cadence-host.c b/drivers/pci/controller/cadence/pcie-cadence-host.c\n>> index 0bc9e6e90e0e0..873d496c440f0 100644\n>> --- a/drivers/pci/controller/cadence/pcie-cadence-host.c\n>> +++ b/drivers/pci/controller/cadence/pcie-cadence-host.c\n>> @@ -370,6 +370,7 @@ void cdns_pcie_host_disable(struct cdns_pcie_rc *rc)\n>>   \n>>   \tcdns_pcie_host_deinit(rc);\n>>   \tcdns_pcie_host_link_disable(rc);\n>> +\tcdns_pcie_debugfs_deinit(&rc->pcie);\n>>   }\n> \n> Should this debugfs teardown be moved to the beginning of the function\n> for the same reason mentioned above?\n\n\nWill change.\n\n\nBest regards,\nHans\n>","headers":{"Return-Path":"\n <linux-pci+bounces-54192-incoming=patchwork.ozlabs.org@vger.kernel.org>","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 (1024-bit key;\n unprotected) header.d=163.com header.i=@163.com header.a=rsa-sha256\n header.s=s110527 header.b=lquLDqNr;\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-54192-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (1024-bit key) header.d=163.com header.i=@163.com\n header.b=\"lquLDqNr\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=117.135.210.4","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=163.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=163.com"],"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 4gBbmY5CW2z1yK7\n\tfor <incoming@patchwork.ozlabs.org>; Fri, 08 May 2026 14:31:41 +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 C8C883036733\n\tfor <incoming@patchwork.ozlabs.org>; Fri,  8 May 2026 04:31:38 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 92F902494D8;\n\tFri,  8 May 2026 04:31:36 +0000 (UTC)","from m16.mail.163.com (m16.mail.163.com [117.135.210.4])\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 A28182367B5\n\tfor <linux-pci@vger.kernel.org>; Fri,  8 May 2026 04:31:33 +0000 (UTC)","from [192.168.50.71] (unknown [])\n\tby gzsmtp5 (Coremail) with SMTP id QCgvCgC3mmoQZ_1pWkbJCw--.142S2;\n\tFri, 08 May 2026 12:31:14 +0800 (CST)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1778214696; cv=none;\n b=pIU+DGETogzS4rEGYPKHylF3z9uTEx9NAH5d4pkYyv6sU4QUSAUlCo0A+bG98u2MP0ESLxM8umqedvHiBCTJVM/Z/pHMitMAPa6AAdkRHe+XKgs4wxLdvt3Sv9D1tEIzWDNPm5TlQia1BysTfHU577BwAI7wmqIqzdjd6cnpto8=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1778214696; c=relaxed/simple;\n\tbh=YFRykaqgq0p0tx19utSc/mGsGV5tKxzrwjPAi8InNRc=;\n\th=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:\n\t In-Reply-To:Content-Type;\n b=hqvHKPFTYtpiJnb3jJA3SQr1YvBFVn3IKeHCZvk0+jhgF7uJNrxwgym2iSbZdtNCjeoSPl6U1/4o7JQJufHxGcueIY2kIM3XiKo6//NmTHU9/WEWFivK1XTjllOqlGXuwintEYPNVpGNNV7/mJbgnnSK54Dje2hKCsYuvYG1Ia4=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=163.com;\n spf=pass smtp.mailfrom=163.com;\n dkim=pass (1024-bit key) header.d=163.com header.i=@163.com\n header.b=lquLDqNr; arc=none smtp.client-ip=117.135.210.4","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com;\n\ts=s110527; h=Message-ID:Date:MIME-Version:Subject:To:From:\n\tContent-Type; bh=zOjzfqdILjuppl54PXVImfO724apQlMc35Rh9swFQtI=;\n\tb=lquLDqNrxjs/oh67RR47nwkcUk+2lC26bv6HU961SpNC0WcZe78XyIgchg3JLP\n\tm1/3KSAOpapWUgRDj1ruCk0b7FuLyAFUfBE1cZKUqn/2KbJshJaTYZ5ztnacGdKE\n\tmmgsBua5CNJFwk/tRUgMDqQpHjnjsj4nsuQZdSayah+vE=","Message-ID":"<10503cf8-2f2c-4a8d-8c24-f1056859edd8@163.com>","Date":"Fri, 8 May 2026 12:31:12 +0800","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"<linux-pci.vger.kernel.org>","List-Subscribe":"<mailto:linux-pci+subscribe@vger.kernel.org>","List-Unsubscribe":"<mailto:linux-pci+unsubscribe@vger.kernel.org>","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH v4 2/2] PCI: cadence: Add debugfs property to provide\n LTSSM status of the PCIe link","To":"sashiko@lists.linux.dev, Manikandan K Pillai <mpillai@cadence.com>","Cc":"linux-pci@vger.kernel.org","References":"<20260508034101.1910036-3-18255117159@163.com>\n <20260508041956.C8F10C2BCB0@smtp.kernel.org>","Content-Language":"en-US","From":"Hans Zhang <18255117159@163.com>","In-Reply-To":"<20260508041956.C8F10C2BCB0@smtp.kernel.org>","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"7bit","X-CM-TRANSID":"QCgvCgC3mmoQZ_1pWkbJCw--.142S2","X-Coremail-Antispam":"1Uf129KBjvJXoW3JrWkKF18Kw1xGry5XF1xGrg_yoWxur4xpa\n\t9rGFyfCF4xXFWYv3Z2v3WUXF1fJF93Aa47Gw4vkw17uFnxuryUuFnrKFW5GrW3WrWqqr12\n\tv3Z8tasrWF43AFDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2\n\t9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0zRYNtsUUUUU=","X-CM-SenderInfo":"rpryjkyvrrlimvzbiqqrwthudrp/xtbCxBK3W2n9ZxK4ZAAA3H"}}]