Linux PCI subsystem development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Hans Zhang" <18255117159@163.com>
Cc: linux-amlogic@lists.infradead.org, imx@lists.linux.dev,
	linux-pci@vger.kernel.org, neil.armstrong@linaro.org,
	Frank.Li@kernel.org
Subject: Re: [PATCH v3 02/16] PCI: dwc: Use cached PCIe capability offset in core
Date: Mon, 20 Jul 2026 15:28:59 +0000	[thread overview]
Message-ID: <20260720152859.B149B1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260720150619.24733-3-18255117159@163.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Uninitialized `pci->pcie_cap` used in Endpoint mode causes severe PCIe configuration space corruption.
- [Low] Unnecessary PCIe capability search and unused variable left intact.
--

--- Patch [2]: [PATCH v3 02/16] PCI: dwc: Use cached PCIe capability offset in core ---
commit 1e2ce6ece477d5f9c179f2ac4c13cd06cf764f59
Author: Hans Zhang <18255117159@163.com>

PCI: dwc: Use cached PCIe capability offset in core
    
Modify the DWC core functions to use the cached pcie_cap offset instead
of calling dw_pcie_find_capability() each time.

[ ... ]

> dw_pcie_ep_init_non_sticky_registers() now assumes pci->pcie_cap is
> valid. if not, it prints a warning and skips the operation. The other
> functions run after probe, so pci->pcie_cap is already valid and can
> be used directly.

[Severity: High]
The commit message mentions adding a warning and skipping the operation if
pci->pcie_cap is not valid, but this check appears to be missing in the
code below.

> diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c
> index 7d2794945704e..14228be8bbce7 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> @@ -1246,7 +1246,7 @@ static void dw_pcie_ep_init_non_sticky_registers(struct dw_pcie *pci)
>  	 * to all other functions as well.
>  	 */
>  	if (funcs > 1) {
> -		offset = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP);
> +		offset = pci->pcie_cap;

[Severity: High]
Without the validation check mentioned in the commit message, if
pci->pcie_cap is uninitialized (0), will this lead to corrupting the
standard PCI configuration space header registers instead of the intended
capability registers?

[ ... ]

> diff --git a/drivers/pci/controller/dwc/pcie-designware.c b/drivers/pci/controller/dwc/pcie-designware.c
> index ec4722ed93032..810729b918928 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.c
> +++ b/drivers/pci/controller/dwc/pcie-designware.c
> @@ -806,8 +806,7 @@ int dw_pcie_wait_for_link(struct dw_pcie *pci)
>  
>  	pci_host_common_link_train_delay(pci->max_link_speed);
>  
> -	offset = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP);
> -	val = dw_pcie_readw_dbi(pci, offset + PCI_EXP_LNKSTA);
> +	val = dw_pcie_readw_dbi(pci, pci->pcie_cap + PCI_EXP_LNKSTA);

[Severity: High]
If pci->pcie_cap is 0, this will read from 0 + PCI_EXP_LNKSTA (0x12) instead
of the actual capability offset. Could this lead to failed link status
checks?

[ ... ]

> @@ -890,7 +889,7 @@ static void dw_pcie_link_set_max_speed(struct dw_pcie *pci)
>  int dw_pcie_link_get_max_link_width(struct dw_pcie *pci)
>  {
>  	u8 cap = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP);
> -	u32 lnkcap = dw_pcie_readl_dbi(pci, cap + PCI_EXP_LNKCAP);
> +	u32 lnkcap = dw_pcie_readl_dbi(pci, pci->pcie_cap + PCI_EXP_LNKCAP);

[Severity: Low]
Is the cap variable still needed here? It looks like it is now unused, which
might cause an unnecessary MMIO read during the capability search and trigger
a compiler warning.

>  	return FIELD_GET(PCI_EXP_LNKCAP_MLW, lnkcap);
>  }
> @@ -898,7 +897,6 @@ int dw_pcie_link_get_max_link_width(struct dw_pcie *pci)
>  static void dw_pcie_link_set_max_link_width(struct dw_pcie *pci, u32 num_lanes)
>  {
>  	u32 lnkcap, lwsc, plc;
> -	u8 cap;
>  
>  	if (!num_lanes)
>  		return;
> @@ -935,10 +933,9 @@ static void dw_pcie_link_set_max_link_width(struct dw_pcie *pci, u32 num_lanes)
>  	dw_pcie_writel_dbi(pci, PCIE_PORT_LINK_CONTROL, plc);
>  	dw_pcie_writel_dbi(pci, PCIE_LINK_WIDTH_SPEED_CONTROL, lwsc);
>  
> -	cap = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP);
> -	lnkcap = dw_pcie_readl_dbi(pci, cap + PCI_EXP_LNKCAP);
> +	lnkcap = dw_pcie_readl_dbi(pci, pci->pcie_cap + PCI_EXP_LNKCAP);
>  	FIELD_MODIFY(PCI_EXP_LNKCAP_MLW, &lnkcap, num_lanes);
> -	dw_pcie_writel_dbi(pci, cap + PCI_EXP_LNKCAP, lnkcap);
> +	dw_pcie_writel_dbi(pci, pci->pcie_cap + PCI_EXP_LNKCAP, lnkcap);
>  }

[Severity: High]
If pci->pcie_cap happens to be 0 here, this will perform a read-modify-write
at offset 0 + PCI_EXP_LNKCAP (0x0C). Could this destroy the standard
PCI Header Type and BIST registers?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720150619.24733-1-18255117159@163.com?part=2

  reply	other threads:[~2026-07-20 15:29 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-20 15:06 [PATCH v3 00/16] PCI: dwc: Cache PCIe capability offset and simplify drivers Hans Zhang
2026-07-20 15:06 ` [PATCH v3 01/16] PCI: dwc: Add pcie_cap field and helper in designware header Hans Zhang
2026-07-20 15:17   ` sashiko-bot
2026-07-20 15:27     ` Hans Zhang
2026-07-20 15:06 ` [PATCH v3 02/16] PCI: dwc: Use cached PCIe capability offset in core Hans Zhang
2026-07-20 15:28   ` sashiko-bot [this message]
2026-07-20 15:06 ` [PATCH v3 03/16] PCI: dwc: imx6: Use cached PCIe capability offset Hans Zhang
2026-07-20 15:28   ` sashiko-bot
2026-07-20 15:06 ` [PATCH v3 04/16] PCI: dwc: layerscape-ep: " Hans Zhang
2026-07-20 15:25   ` sashiko-bot
2026-07-20 15:06 ` [PATCH v3 05/16] PCI: dwc: meson: " Hans Zhang
2026-07-20 15:17   ` sashiko-bot
2026-07-20 15:06 ` [PATCH v3 06/16] PCI: dwc: rockchip: " Hans Zhang
2026-07-20 15:21   ` sashiko-bot
2026-07-20 15:06 ` [PATCH v3 07/16] PCI: dwc: eswin: " Hans Zhang
2026-07-20 15:15   ` sashiko-bot
2026-07-20 15:06 ` [PATCH v3 08/16] PCI: dwc: fu740: " Hans Zhang
2026-07-20 15:26   ` sashiko-bot
2026-07-20 15:06 ` [PATCH v3 09/16] PCI: dwc: intel-gw: " Hans Zhang
2026-07-20 15:23   ` sashiko-bot
2026-07-20 15:06 ` [PATCH v3 10/16] PCI: dwc: qcom-ep: " Hans Zhang
2026-07-20 15:29   ` sashiko-bot
2026-07-20 15:06 ` [PATCH v3 11/16] PCI: dwc: qcom: " Hans Zhang
2026-07-20 15:19   ` sashiko-bot
2026-07-20 15:06 ` [PATCH v3 12/16] PCI: dwc: sophgo: " Hans Zhang
2026-07-20 15:20   ` sashiko-bot
2026-07-20 15:06 ` [PATCH v3 13/16] PCI: dwc: spacemit-k1: " Hans Zhang
2026-07-20 15:19   ` sashiko-bot
2026-07-20 15:06 ` [PATCH v3 14/16] PCI: dwc: spear13xx: " Hans Zhang
2026-07-20 15:27   ` sashiko-bot
2026-07-20 15:06 ` [PATCH v3 15/16] PCI: dwc: tegra194: " Hans Zhang
2026-07-20 15:30   ` sashiko-bot
2026-07-20 15:06 ` [PATCH v3 16/16] PCI: dwc: ultrarisc: " Hans Zhang
2026-07-20 15:33   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260720152859.B149B1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=18255117159@163.com \
    --cc=Frank.Li@kernel.org \
    --cc=imx@lists.linux.dev \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=neil.armstrong@linaro.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox