Linux PCI subsystem development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Hans Zhang" <18255117159@163.com>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH v2 15/16] PCI: dwc: tegra194: Use cached PCIe capability offset
Date: Sat, 30 May 2026 16:06:45 +0000	[thread overview]
Message-ID: <20260530160645.D19DD1F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260530153101.695580-16-18255117159@163.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Calling `dw_pcie_get_pcie_cap()` during `dw_pcie_ep_init()` causes a synchronous external abort in Tegra194 Endpoint mode because the hardware is unclocked.
--

commit 240e0a20036fb631179ee7e94b3f17f4d5523ad8
Author: Hans Zhang <18255117159@163.com>

PCI: dwc: tegra194: Use cached PCIe capability offset

This patch updates the Tegra194 PCIe host and endpoint initialization paths to
use dw_pcie_get_pcie_cap() to retrieve and cache the capability offset. The
commit message explains that this is safe because the driver has already
enabled the hardware before these functions are called.

> In endpoint mode: pex_ep_event_pex_rst_deassert() runs before
> dw_pcie_ep_init(), but the driver has already enabled hardware.
> dw_pcie_get_pcie_cap() will perform the DBI read and cache the offset.

[Severity: High]
Is this sequence accurate for the endpoint mode?

Looking at tegra_pcie_config_ep() in pcie-tegra194.c, dw_pcie_ep_init() is
invoked synchronously during device probe:

tegra_pcie_config_ep()
    dw_pcie_ep_init()

This happens before the endpoint hardware clocks and power domains are
enabled, because clock enablement is deferred until the PERST# interrupt
triggers pex_ep_event_pex_rst_deassert().

Since a prior commit in this series modified dw_pcie_ep_init() in
pcie-designware-ep.c to unconditionally cache the PCIe capability offset by
calling dw_pcie_get_pcie_cap(), this triggers an early DBI read.

Will this MMIO read on the unclocked PCIe controller trigger a synchronous
external abort on Tegra platforms and cause a kernel panic during boot?

> diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c b/drivers/pci/controller/dwc/pcie-tegra194.c
> index 795cef5a915dc..bf482bc66a929 100644
> --- a/drivers/pci/controller/dwc/pcie-tegra194.c
> +++ b/drivers/pci/controller/dwc/pcie-tegra194.c
[ ... ]
> @@ -1889,8 +1888,7 @@ static void pex_ep_event_pex_rst_deassert(struct tegra_pcie_dw *pcie)
>  		dw_pcie_writel_dbi(pci, GEN3_RELATED_OFF, val);
>  	}
>  
> -	pcie->pcie_cap_base = dw_pcie_find_capability(&pcie->pci,
> -						      PCI_CAP_ID_EXP);
> +	pcie->pcie_cap_base = dw_pcie_get_pcie_cap(pci);
>  
>  	/* Clear Slot Clock Configuration bit if SRNS configuration */
>  	if (pcie->enable_srns) {

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

  reply	other threads:[~2026-05-30 16:06 UTC|newest]

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

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=20260530160645.D19DD1F00893@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=18255117159@163.com \
    --cc=linux-pci@vger.kernel.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