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
WARNING: multiple messages have this Message-ID (diff)
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
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
next prev parent reply other threads:[~2026-07-20 15:29 UTC|newest]
Thread overview: 102+ 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 ` Hans Zhang
2026-07-20 15:06 ` Hans Zhang
2026-07-20 15:06 ` 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:06 ` Hans Zhang
2026-07-20 15:06 ` Hans Zhang
2026-07-20 15:06 ` Hans Zhang
2026-07-20 15:17 ` sashiko-bot
2026-07-20 15:17 ` sashiko-bot
2026-07-20 15:27 ` Hans Zhang
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:06 ` Hans Zhang
2026-07-20 15:06 ` Hans Zhang
2026-07-20 15:06 ` Hans Zhang
2026-07-20 15:28 ` sashiko-bot [this message]
2026-07-20 15:28 ` sashiko-bot
2026-07-20 15:06 ` [PATCH v3 03/16] PCI: dwc: imx6: Use cached PCIe capability offset Hans Zhang
2026-07-20 15:06 ` Hans Zhang
2026-07-20 15:06 ` Hans Zhang
2026-07-20 15:06 ` Hans Zhang
2026-07-20 15:28 ` sashiko-bot
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:06 ` Hans Zhang
2026-07-20 15:06 ` Hans Zhang
2026-07-20 15:06 ` Hans Zhang
2026-07-20 15:25 ` sashiko-bot
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:06 ` Hans Zhang
2026-07-20 15:06 ` Hans Zhang
2026-07-20 15:06 ` Hans Zhang
2026-07-20 15:17 ` sashiko-bot
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:06 ` Hans Zhang
2026-07-20 15:06 ` Hans Zhang
2026-07-20 15:06 ` Hans Zhang
2026-07-20 15:21 ` sashiko-bot
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:06 ` Hans Zhang
2026-07-20 15:06 ` Hans Zhang
2026-07-20 15:06 ` Hans Zhang
2026-07-20 15:15 ` sashiko-bot
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:06 ` Hans Zhang
2026-07-20 15:06 ` Hans Zhang
2026-07-20 15:06 ` Hans Zhang
2026-07-20 15:26 ` sashiko-bot
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:06 ` Hans Zhang
2026-07-20 15:06 ` Hans Zhang
2026-07-20 15:06 ` Hans Zhang
2026-07-20 15:23 ` sashiko-bot
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:06 ` Hans Zhang
2026-07-20 15:06 ` Hans Zhang
2026-07-20 15:06 ` Hans Zhang
2026-07-20 15:29 ` sashiko-bot
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:06 ` Hans Zhang
2026-07-20 15:06 ` Hans Zhang
2026-07-20 15:06 ` Hans Zhang
2026-07-20 15:19 ` sashiko-bot
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:06 ` Hans Zhang
2026-07-20 15:06 ` Hans Zhang
2026-07-20 15:06 ` Hans Zhang
2026-07-20 15:20 ` sashiko-bot
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:06 ` Hans Zhang
2026-07-20 15:06 ` Hans Zhang
2026-07-20 15:06 ` Hans Zhang
2026-07-20 15:19 ` sashiko-bot
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:06 ` Hans Zhang
2026-07-20 15:06 ` Hans Zhang
2026-07-20 15:06 ` Hans Zhang
2026-07-20 15:27 ` sashiko-bot
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:06 ` Hans Zhang
2026-07-20 15:06 ` Hans Zhang
2026-07-20 15:06 ` Hans Zhang
2026-07-20 15:30 ` sashiko-bot
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:06 ` Hans Zhang
2026-07-20 15:06 ` Hans Zhang
2026-07-20 15:06 ` Hans Zhang
2026-07-20 15:33 ` sashiko-bot
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.