[{"id":3685407,"web_url":"http://patchwork.ozlabs.org/comment/3685407/","msgid":"<20260503165243.4A676C2BCB4@smtp.kernel.org>","list_archive_url":null,"date":"2026-05-03T16:52:42","subject":"Re: [PATCH] PCI: cadence: Use cdns_pcie_find_capability() to get\n PCIe Cap offset in host driver","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 1 potential issue(s) to consider:\n- [Critical] cdns_pcie_find_capability() searches the wrong register space in Host mode and its return value is not validated, leading to Root Port configuration space corruption.\n--\n\ncommit 09b3c64b8f5892eb365acd13030a8067652a15e8\nAuthor: Hans Zhang <18255117159@163.com>\n\nPCI: cadence: Use cdns_pcie_find_capability() to get PCIe Cap offset in host driver\n\nThis commit replaces the hardcoded CDNS_PCIE_RP_CAP_OFFSET with a dynamic\nlookup using cdns_pcie_find_capability() in Cadence PCIe host-related\nfunctions. The goal is to ensure correct operation across various SoC designs\nwhere the capability might not reside at offset 0xC0.\n\n> diff --git a/drivers/pci/controller/cadence/pcie-cadence-host-common.c b/drivers/pci/controller/cadence/pcie-cadence-host-common.c\n> index 2b0211870f02..5013d3fe23b5 100644\n> --- a/drivers/pci/controller/cadence/pcie-cadence-host-common.c\n> +++ b/drivers/pci/controller/cadence/pcie-cadence-host-common.c\n> @@ -26,14 +26,14 @@ EXPORT_SYMBOL_GPL(bar_max_size);\n>  \n>  int cdns_pcie_host_training_complete(struct cdns_pcie *pcie)\n>  {\n> -\tu32 pcie_cap_off = CDNS_PCIE_RP_CAP_OFFSET;\n>  \tunsigned long end_jiffies;\n>  \tu16 lnk_stat;\n> +\tu8 cap = cdns_pcie_find_capability(pcie, PCI_CAP_ID_EXP);\n\nDoes this capability search scan the correct register space when operating in\nhost mode?\n\nLooking at the helper function, it uses cdns_pcie_read_cfg() which reads\ndirectly from the base address without the Root Port offset:\n\ndrivers/pci/controller/cadence/pcie-cadence.c:cdns_pcie_find_capability() {\n    return PCI_FIND_NEXT_CAP(cdns_pcie_read_cfg, PCI_CAPABILITY_LIST,\n                             cap, NULL, pcie);\n}\n\nHowever, the Root Port configuration registers are physically located at\npcie->reg_base + CDNS_PCIE_RP_BASE. Could this cause the search to scan the\nLocal Management register space instead, failing to find PCI_CAP_ID_EXP\nand returning 0?\n\n[ ... ]\n\n> @@ -68,27 +68,26 @@ EXPORT_SYMBOL_GPL(cdns_pcie_host_wait_for_link);\n>  int cdns_pcie_retrain(struct cdns_pcie *pcie,\n>  \t\t      cdns_pcie_linkup_func pcie_link_up)\n>  {\n> -\tu32 lnk_cap_sls, pcie_cap_off = CDNS_PCIE_RP_CAP_OFFSET;\n> +\tu32 lnk_cap_sls;\n>  \tu16 lnk_stat, lnk_ctl;\n>  \tint ret = 0;\n> +\tu8 cap = cdns_pcie_find_capability(pcie, PCI_CAP_ID_EXP);\n>  \n>  \t/*\n>  \t * Set retrain bit if current speed is 2.5 GB/s,\n>  \t * but the PCIe root port support is > 2.5 GB/s.\n>  \t */\n>  \n> -\tlnk_cap_sls = cdns_pcie_readl(pcie, (CDNS_PCIE_RP_BASE + pcie_cap_off +\n> +\tlnk_cap_sls = cdns_pcie_readl(pcie, (CDNS_PCIE_RP_BASE + cap +\n>  \t\t\t\t\t     PCI_EXP_LNKCAP));\n\nIf the capability is not found and cap evaluates to 0, is it safe to proceed\nwithout validating the return value?\n\nSince the fallback value would be 0, evaluating cap + PCI_EXP_LNKCAP will\nresult in an offset of 0x0C.\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 0bc9e6e90e0e..2a3fd41c1cf4 100644\n> --- a/drivers/pci/controller/cadence/pcie-cadence-host.c\n> +++ b/drivers/pci/controller/cadence/pcie-cadence-host.c\n> @@ -147,12 +148,12 @@ static int cdns_pcie_host_init_root_port(struct cdns_pcie_rc *rc)\n>  \tcdns_pcie_rp_writeb(pcie, PCI_CLASS_PROG, 0);\n>  \tcdns_pcie_rp_writew(pcie, PCI_CLASS_DEVICE, PCI_CLASS_BRIDGE_PCI);\n>  \n> -\tvalue = cdns_pcie_rp_readl(pcie, CDNS_PCIE_RP_CAP_OFFSET + PCI_EXP_LNKCAP);\n> +\tvalue = cdns_pcie_rp_readl(pcie, cap + PCI_EXP_LNKCAP);\n>  \tif (rc->quirk_broken_aspm_l0s)\n>  \t\tvalue &= ~PCI_EXP_LNKCAP_ASPM_L0S;\n>  \tif (rc->quirk_broken_aspm_l1)\n>  \t\tvalue &= ~PCI_EXP_LNKCAP_ASPM_L1;\n> -\tcdns_pcie_rp_writel(pcie, CDNS_PCIE_RP_CAP_OFFSET + PCI_EXP_LNKCAP, value);\n> +\tcdns_pcie_rp_writel(pcie, cap + PCI_EXP_LNKCAP, value);\n\nWill this overwrite the wrong configuration registers if cap is 0?\n\nThe cdns_pcie_rp_writel() function automatically adds CDNS_PCIE_RP_BASE to\nthe destination offset. If cap is 0, writing to cap + PCI_EXP_LNKCAP will\naccess offset 0x0C.\n\nCould this regression unintentionally clobber the standard Type 1 PCI header\nregisters, such as the Cache Line Size and Latency Timer, and corrupt the\nRoot Port hardware state?","headers":{"Return-Path":"\n <linux-pci+bounces-53643-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=fIDcM2mk;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.234.253.10; helo=sea.lore.kernel.org;\n envelope-from=linux-pci+bounces-53643-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=\"fIDcM2mk\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org [172.234.253.10])\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 4g7rT63b5lz1yJV\n\tfor <incoming@patchwork.ozlabs.org>; Mon, 04 May 2026 02:53:46 +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 CAE913011872\n\tfor <incoming@patchwork.ozlabs.org>; Sun,  3 May 2026 16:52:45 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 6B0443CF67F;\n\tSun,  3 May 2026 16:52:45 +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 71F6B34C80D\n\tfor <linux-pci@vger.kernel.org>; Sun,  3 May 2026 16:52:44 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 4A676C2BCB4;\n\tSun,  3 May 2026 16:52:43 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1777827164; cv=none;\n b=sA4msISlXBtljflC8UdgfCmareqMoV/uuz+eAS3IQ7AGxpow0qdiUpBNqsCBspxM6YwmfhdA6NS8u6ZYpO6X/pg1KMlVoZ3XnueD6LyrI9iu5cMV9EPNbtPM0NfZ7ngCiHKWwpo/J4tAiiI+ahINaqKK7I0NUnNmgaIS+M5g5Gs=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1777827164; c=relaxed/simple;\n\tbh=c9hEDcaBbMm+9MIAJ2OXdE0ANuWKycOgxmrQkGpzH1k=;\n\th=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date:\n\t Message-Id;\n b=UkBPp4lDeqFrhFq5D7wGf+oseCI7majx1/2qTUcZE9sOx2Kbbmch4nzggAXKnt61QM+b5+RQRQHTEcl3MNg+8tk0fYQXWTIRt5UkxuCJ/0DRsdL0AF9K5rdDBUYFaKywSUB3ULRIuyq54dxp0HMqEpTteWCSHBXcnMjbfunuPiU=","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=fIDcM2mk; 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=1777827163;\n\tbh=c9hEDcaBbMm+9MIAJ2OXdE0ANuWKycOgxmrQkGpzH1k=;\n\th=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date:From;\n\tb=fIDcM2mkvjJLA02k8kx+rZTBNdsuktdGfA4OrYlZOpdtRjdR1PP+my7cCI5c2rhPR\n\t zXmQ9w6DZsdb2KYvRV7C+JS4B1ufO1gQSudOEVxDCnQOht58PhuZVmxRH+Zwx87xa5\n\t JtH3AiNzrM8dXyb+Cp8jCbIcYcOU5CRRlVMu89I19Vxik/FzLL3iqqrITMkT4ObPNH\n\t TFrKqAW4hSYB4YT8vWL5VhcF4UnZNXNT/66UZs0zUzS5BV7BH9MpiVgAEfHNsvW7VI\n\t 6bhdz/Dqm0tP69p/GJyE28gB2mQT8vmrGZucYgzjbs+4i3i8MXJhYizecfhYE9VXtb\n\t DeKjN35BDFkPQ==","From":"sashiko-bot@kernel.org","Subject":"Re: [PATCH] PCI: cadence: Use cdns_pcie_find_capability() to get\n PCIe Cap offset in host driver","Reply-To":"sashiko@lists.linux.dev","To":"\"Hans Zhang\" <18255117159@163.com>","Cc":"linux-pci@vger.kernel.org","In-Reply-To":"<20260503161913.77878-1-18255117159@163.com>","References":"<20260503161913.77878-1-18255117159@163.com>","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"quoted-printable","Date":"Sun, 03 May 2026 16:52:42 +0000","Message-Id":"<20260503165243.4A676C2BCB4@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":3685577,"web_url":"http://patchwork.ozlabs.org/comment/3685577/","msgid":"<5823faec-d972-4c77-90ec-a215c686e0a8@163.com>","list_archive_url":null,"date":"2026-05-04T08:22:26","subject":"Re: [PATCH] PCI: cadence: Use cdns_pcie_find_capability() to get PCIe\n Cap offset in host driver","submitter":{"id":89937,"url":"http://patchwork.ozlabs.org/api/people/89937/","name":"Hans Zhang","email":"18255117159@163.com"},"content":"On 5/4/26 00:52, sashiko-bot@kernel.org wrote:\n> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:\n> - [Critical] cdns_pcie_find_capability() searches the wrong register space in Host mode and its return value is not validated, leading to Root Port configuration space corruption.\n> --\n> \n> commit 09b3c64b8f5892eb365acd13030a8067652a15e8\n> Author: Hans Zhang <18255117159@163.com>\n> \n> PCI: cadence: Use cdns_pcie_find_capability() to get PCIe Cap offset in host driver\n> \n> This commit replaces the hardcoded CDNS_PCIE_RP_CAP_OFFSET with a dynamic\n> lookup using cdns_pcie_find_capability() in Cadence PCIe host-related\n> functions. The goal is to ensure correct operation across various SoC designs\n> where the capability might not reside at offset 0xC0.\n> \n>> diff --git a/drivers/pci/controller/cadence/pcie-cadence-host-common.c b/drivers/pci/controller/cadence/pcie-cadence-host-common.c\n>> index 2b0211870f02..5013d3fe23b5 100644\n>> --- a/drivers/pci/controller/cadence/pcie-cadence-host-common.c\n>> +++ b/drivers/pci/controller/cadence/pcie-cadence-host-common.c\n>> @@ -26,14 +26,14 @@ EXPORT_SYMBOL_GPL(bar_max_size);\n>>   \n>>   int cdns_pcie_host_training_complete(struct cdns_pcie *pcie)\n>>   {\n>> -\tu32 pcie_cap_off = CDNS_PCIE_RP_CAP_OFFSET;\n>>   \tunsigned long end_jiffies;\n>>   \tu16 lnk_stat;\n>> +\tu8 cap = cdns_pcie_find_capability(pcie, PCI_CAP_ID_EXP);\n> \n> Does this capability search scan the correct register space when operating in\n> host mode?\n> \n> Looking at the helper function, it uses cdns_pcie_read_cfg() which reads\n> directly from the base address without the Root Port offset:\n> \n> drivers/pci/controller/cadence/pcie-cadence.c:cdns_pcie_find_capability() {\n>      return PCI_FIND_NEXT_CAP(cdns_pcie_read_cfg, PCI_CAPABILITY_LIST,\n>                               cap, NULL, pcie);\n> }\n> \n> However, the Root Port configuration registers are physically located at\n> pcie->reg_base + CDNS_PCIE_RP_BASE. Could this cause the search to scan the\n> Local Management register space instead, failing to find PCI_CAP_ID_EXP\n> and returning 0?\n\nI don't think we need to worry about this issue.\n\nAs per PCIe r7.0, sec 7.5.1.1.11, Since all PCI Express Functions\n\nare required to implement the PCI Express Capability structure, which \nmust be included somewhere in this linked list;\n\nSo, it won't return 0 here.\n\nBest regards,\nHans\n\n\n> \n> [ ... ]\n> \n>> @@ -68,27 +68,26 @@ EXPORT_SYMBOL_GPL(cdns_pcie_host_wait_for_link);\n>>   int cdns_pcie_retrain(struct cdns_pcie *pcie,\n>>   \t\t      cdns_pcie_linkup_func pcie_link_up)\n>>   {\n>> -\tu32 lnk_cap_sls, pcie_cap_off = CDNS_PCIE_RP_CAP_OFFSET;\n>> +\tu32 lnk_cap_sls;\n>>   \tu16 lnk_stat, lnk_ctl;\n>>   \tint ret = 0;\n>> +\tu8 cap = cdns_pcie_find_capability(pcie, PCI_CAP_ID_EXP);\n>>   \n>>   \t/*\n>>   \t * Set retrain bit if current speed is 2.5 GB/s,\n>>   \t * but the PCIe root port support is > 2.5 GB/s.\n>>   \t */\n>>   \n>> -\tlnk_cap_sls = cdns_pcie_readl(pcie, (CDNS_PCIE_RP_BASE + pcie_cap_off +\n>> +\tlnk_cap_sls = cdns_pcie_readl(pcie, (CDNS_PCIE_RP_BASE + cap +\n>>   \t\t\t\t\t     PCI_EXP_LNKCAP));\n> \n> If the capability is not found and cap evaluates to 0, is it safe to proceed\n> without validating the return value?\n> \n> Since the fallback value would be 0, evaluating cap + PCI_EXP_LNKCAP will\n> result in an offset of 0x0C.\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 0bc9e6e90e0e..2a3fd41c1cf4 100644\n>> --- a/drivers/pci/controller/cadence/pcie-cadence-host.c\n>> +++ b/drivers/pci/controller/cadence/pcie-cadence-host.c\n>> @@ -147,12 +148,12 @@ static int cdns_pcie_host_init_root_port(struct cdns_pcie_rc *rc)\n>>   \tcdns_pcie_rp_writeb(pcie, PCI_CLASS_PROG, 0);\n>>   \tcdns_pcie_rp_writew(pcie, PCI_CLASS_DEVICE, PCI_CLASS_BRIDGE_PCI);\n>>   \n>> -\tvalue = cdns_pcie_rp_readl(pcie, CDNS_PCIE_RP_CAP_OFFSET + PCI_EXP_LNKCAP);\n>> +\tvalue = cdns_pcie_rp_readl(pcie, cap + PCI_EXP_LNKCAP);\n>>   \tif (rc->quirk_broken_aspm_l0s)\n>>   \t\tvalue &= ~PCI_EXP_LNKCAP_ASPM_L0S;\n>>   \tif (rc->quirk_broken_aspm_l1)\n>>   \t\tvalue &= ~PCI_EXP_LNKCAP_ASPM_L1;\n>> -\tcdns_pcie_rp_writel(pcie, CDNS_PCIE_RP_CAP_OFFSET + PCI_EXP_LNKCAP, value);\n>> +\tcdns_pcie_rp_writel(pcie, cap + PCI_EXP_LNKCAP, value);\n> \n> Will this overwrite the wrong configuration registers if cap is 0?\n> \n> The cdns_pcie_rp_writel() function automatically adds CDNS_PCIE_RP_BASE to\n> the destination offset. If cap is 0, writing to cap + PCI_EXP_LNKCAP will\n> access offset 0x0C.\n> \n> Could this regression unintentionally clobber the standard Type 1 PCI header\n> registers, such as the Cache Line Size and Latency Timer, and corrupt the\n> Root Port hardware state?\n>","headers":{"Return-Path":"\n <linux-pci+bounces-53664-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=AB1V9yiT;\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-53664-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=\"AB1V9yiT\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=117.135.210.5","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 4g8F551PbMz1y04\n\tfor <incoming@patchwork.ozlabs.org>; Mon, 04 May 2026 18:22:49 +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 DD538300D726\n\tfor <incoming@patchwork.ozlabs.org>; Mon,  4 May 2026 08:22:41 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 8B3BE3290D2;\n\tMon,  4 May 2026 08:22:41 +0000 (UTC)","from m16.mail.163.com (m16.mail.163.com [117.135.210.5])\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 1663C314A84\n\tfor <linux-pci@vger.kernel.org>; Mon,  4 May 2026 08:22:37 +0000 (UTC)","from [192.168.50.71] (unknown [])\n\tby gzga-smtp-mtada-g1-3 (Coremail) with SMTP id\n _____wDnv0tCV_hpNNjUDA--.14088S2;\n\tMon, 04 May 2026 16:22:27 +0800 (CST)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1777882961; cv=none;\n b=DehYYh/h8A2Kgb2O86KIfzxpQ7m6tjm6SZ8rvlV3umMdBU9lOaM2FCROogFshB/J9YXijunrJvdarYaVwrpDOTM7Qcngx3h6CMpRKqlVowTcvu33Lg47y7tKr4e3TQu1xtZcnw5bRGdfoaCKPjyKyOOGCChSjbDVBtNvrFWOKNw=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1777882961; c=relaxed/simple;\n\tbh=ZTTJkhmcxly0uSBJHLNzBkDsEma5FfJo/2uaz1jLFMk=;\n\th=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:\n\t In-Reply-To:Content-Type;\n b=iCHA/TIl+sQ+Qs3rR7KG6hPWP08OrJ0vZ7ja/J5E3EJaAWrWkkL9Bzf4ldus/GQjqlPdmpbmKo7LH7r+6k6sy2pl/sydwsm9m4h9amOMq+YNdt1796pxoP3AdMev3PJE3eDMmwkN+wmEBwudbKnE01PISHASWP/Ow1ZsZSyKNm0=","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=AB1V9yiT; arc=none smtp.client-ip=117.135.210.5","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=WOWFWuQ6Aa/jVM4ZrUesSe5Ka2GKpNHDgEray8AQmS8=;\n\tb=AB1V9yiTMyzK9zyh/ARyxErog+hpntZh3+3+L73nlI6Sdqo2plX6Dd09hHNSux\n\tRVJv5QDGV1i1y8DGu/xCtvWEm5Z3OCEPvB/nXa/tehCzU3RsdHcvNL/ySgGgHQbD\n\t7WHGFQ93gBO5PrQ17mTyqkRyEafad6M8P2ARrxFWTbWvM=","Message-ID":"<5823faec-d972-4c77-90ec-a215c686e0a8@163.com>","Date":"Mon, 4 May 2026 16:22:26 +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] PCI: cadence: Use cdns_pcie_find_capability() to get PCIe\n Cap offset in host driver","To":"sashiko@lists.linux.dev","Cc":"linux-pci@vger.kernel.org","References":"<20260503161913.77878-1-18255117159@163.com>\n <20260503165243.4A676C2BCB4@smtp.kernel.org>","Content-Language":"en-US","From":"Hans Zhang <18255117159@163.com>","In-Reply-To":"<20260503165243.4A676C2BCB4@smtp.kernel.org>","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"7bit","X-CM-TRANSID":"_____wDnv0tCV_hpNNjUDA--.14088S2","X-Coremail-Antispam":"1Uf129KBjvJXoWxuryDAw18KFy5Xry3tFW5Wrg_yoWrKw15pF\n\tZ5W3WIk3W0qr429r4vy3Z8ZF13GF9Iya47tayvkw13XF17CFyDKF42kF13GF43GrsrJr17\n\tX3yDta9xu3WayFUanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2\n\t9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0zRYNtsUUUUU=","X-CM-SenderInfo":"rpryjkyvrrlimvzbiqqrwthudrp/xtbC6wN+Imn4V0NdvgAA3S"}}]