From: sashiko-bot@kernel.org
To: "Krishna Chaitanya Chundru" <krishna.chundru@oss.qualcomm.com>
Cc: conor+dt@kernel.org, linux-pci@vger.kernel.org, robh@kernel.org,
devicetree@vger.kernel.org, olteanv@gmail.com,
linux-phy@lists.infradead.org, vkoul@kernel.org,
neil.armstrong@linaro.org
Subject: Re: [PATCH 4/6] PCI: qcom-ep: Set initial interconnect bandwidth before enabling clocks
Date: Mon, 21 Sep 2026 11:25:07 +0000 [thread overview]
Message-ID: <20260921112507.DBE301F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260921-monaco_ep-v1-4-63c5282fb0db@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] pci: asymmetric resource teardown in qcom_pcie_disable_resources()
--
commit e8d1ed8b0977eb318a03b77e20d6636bb30f02d4
Author: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
PCI: qcom-ep: Set initial interconnect bandwidth before enabling clocks
Some Qualcomm platforms require the interconnect bandwidth constraints
to be set before enabling the interconnect clocks, otherwise some
clocks get stuck in the off state. Move the icc_set_bw() call before
clk_bulk_prepare_enable() so the bandwidth vote is in place first.
> diff --git a/drivers/pci/controller/dwc/pcie-qcom-ep.c b/drivers/pci/controller/dwc/pcie-qcom-ep.c
> index 56184e6ca6e69..0b23d7181539d 100644
> --- a/drivers/pci/controller/dwc/pcie-qcom-ep.c
> +++ b/drivers/pci/controller/dwc/pcie-qcom-ep.c
> @@ -331,9 +331,23 @@ static int qcom_pcie_enable_resources(struct qcom_pcie_ep *pcie_ep)
> struct dw_pcie *pci = &pcie_ep->pci;
> int ret;
>
> + /*
> + * Some Qualcomm platforms require interconnect bandwidth constraints
> + * to be set before enabling interconnect clocks.
> + *
> + * Set an initial peak bandwidth corresponding to single-lane Gen 1
> + * for the pcie-mem path.
> + */
> + ret = icc_set_bw(pcie_ep->icc_mem, 0, QCOM_PCIE_LINK_SPEED_TO_BW(1));
> + if (ret) {
> + dev_err(pci->dev, "failed to set interconnect bandwidth: %d\n",
> + ret);
> + return ret;
> + }
> +
> ret = clk_bulk_prepare_enable(pcie_ep->num_clks, pcie_ep->clks);
> if (ret)
> - return ret;
> + goto err_disable_icc;
[ ... ]
> @@ -351,28 +365,14 @@ static int qcom_pcie_enable_resources(struct qcom_pcie_ep *pcie_ep)
> if (ret)
> goto err_phy_exit;
>
> return 0;
>
> -err_phy_off:
> - phy_power_off(pcie_ep->phy);
> err_phy_exit:
> phy_exit(pcie_ep->phy);
> err_disable_clk:
> clk_bulk_disable_unprepare(pcie_ep->num_clks, pcie_ep->clks);
> +err_disable_icc:
> + icc_set_bw(pcie_ep->icc_mem, 0, 0);
>
> return ret;
> }
[Severity: High]
Does qcom_pcie_disable_resources() also need to be updated to match this new
LIFO teardown ordering?
Since this patch moves the interconnect bandwidth enablement to be the first
step in qcom_pcie_enable_resources(), LIFO ordering requires it to be the last
step disabled. The error path here handles it correctly, but
qcom_pcie_disable_resources() still drops the interconnect bandwidth constraint
before disabling the PHY and clocks:
drivers/pci/controller/dwc/pcie-qcom-ep.c:qcom_pcie_disable_resources() {
...
icc_set_bw(pcie_ep->icc_mem, 0, 0);
phy_power_off(pcie_ep->phy);
phy_exit(pcie_ep->phy);
clk_bulk_disable_unprepare(pcie_ep->num_clks, pcie_ep->clks);
}
When the host asserts PERST, qcom_pcie_disable_resources() is called. Could
this order of teardown lead to bus hangs, NOC errors, or clocks getting stuck
in an invalid state if the interconnect powers down while dependent clocks are
still active?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260921-monaco_ep-v1-0-63c5282fb0db@oss.qualcomm.com?part=4
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
next prev parent reply other threads:[~2026-09-21 11:25 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-21 10:58 [PATCH 0/6] PCI: qcom-ep: Add PCIe Endpoint support for Monaco Krishna Chaitanya Chundru
2026-09-21 10:58 ` [PATCH 1/6] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add qcs8300 16 GT/s PHY Krishna Chaitanya Chundru
2026-09-21 11:05 ` sashiko-bot
2026-09-25 13:10 ` Krzysztof Kozlowski
2026-09-21 10:58 ` [PATCH 2/6] dt-bindings: PCI: qcom-ep: Add QCS8300 compatible Krishna Chaitanya Chundru
2026-09-21 11:10 ` sashiko-bot
2026-09-25 13:16 ` Krzysztof Kozlowski
2026-09-21 10:58 ` [PATCH 3/6] phy: qcom: qmp-pcie: Add endpoint PHY configuration for QCS8300 Krishna Chaitanya Chundru
2026-09-21 11:19 ` sashiko-bot
2026-09-23 12:19 ` Konrad Dybcio
2026-09-23 12:30 ` Krishna Chaitanya Chundru
2026-09-25 15:32 ` Manivannan Sadhasivam
2026-09-21 10:58 ` [PATCH 4/6] PCI: qcom-ep: Set initial interconnect bandwidth before enabling clocks Krishna Chaitanya Chundru
2026-09-21 11:25 ` sashiko-bot [this message]
2026-09-21 10:58 ` [PATCH 5/6] arm64: qcom: monaco: Fix pcie1_phy compatible to list qcs8300 first Krishna Chaitanya Chundru
2026-09-21 11:30 ` sashiko-bot
2026-09-23 12:32 ` Konrad Dybcio
2026-09-21 10:58 ` [PATCH 6/6] arm64: qcom: monaco: Add PCIe Endpoint nodes Krishna Chaitanya Chundru
2026-09-21 11:40 ` 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=20260921112507.DBE301F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krishna.chundru@oss.qualcomm.com \
--cc=linux-pci@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=neil.armstrong@linaro.org \
--cc=olteanv@gmail.com \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=vkoul@kernel.org \
/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