Devicetree
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Krishna Chaitanya Chundru" <krishna.chundru@oss.qualcomm.com>
Cc: olteanv@gmail.com, conor+dt@kernel.org,
	neil.armstrong@linaro.org, linux-phy@lists.infradead.org,
	vkoul@kernel.org, robh@kernel.org, devicetree@vger.kernel.org,
	linux-pci@vger.kernel.org
Subject: Re: [PATCH 6/6] arm64: qcom: monaco: Add PCIe Endpoint nodes
Date: Mon, 21 Sep 2026 11:40:32 +0000	[thread overview]
Message-ID: <20260921114033.644391F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260921-monaco_ep-v1-6-63c5282fb0db@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] dts: qcom: spurious PCIe WAKE# assertion due to output-low
--

commit e087a4ad529c59501ceaa5d2b1a9d03392103204
Author: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>

arm64: qcom: monaco: Add PCIe Endpoint nodes

This commit adds two PCIe controllers that can operate in Endpoint mode for
Monaco. It describes the Endpoint nodes for both controllers, including their
register regions, clocks, interrupts, interconnects, and PHY connections.

> diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
> index d7d135e87a8c7..8f2f0941383aa 100644
> --- a/arch/arm64/boot/dts/qcom/monaco.dtsi
> +++ b/arch/arm64/boot/dts/qcom/monaco.dtsi

[ ... ]

> @@ -6225,6 +6323,52 @@ tlmm: pinctrl@f100000 {
>  			#interrupt-cells = <2>;
>  			wakeup-parent = <&pdc>;
>  
> +			pcie0_ep_default_state: pcie0-ep-default-state {
> +				wake-pins {
> +					pins = "gpio0";
> +					function = "gpio";
> +					drive-strength = <2>;
> +					output-low;

[Severity: Medium]
Will configuring this pin as output-low cause a spurious PCIe WAKE# assertion?

Since the endpoint nodes omit wake-gpios, the endpoint driver in
drivers/pci/controller/dwc/pcie-qcom-ep.c will not request the GPIO to
logically de-assert it. Because this configures the pin to output 0V, won't
the active-low WAKE# signal remain permanently driven low by default?

This could cause the endpoint to continuously assert the WAKE# signal to the
host, potentially preventing the host from sleeping or causing a wake
interrupt storm.

> +				};
> +
> +				clkreq-pins {

[ ... ]

> +			pcie1_ep_default_state: pcie1-ep-default-state {
> +				wake-pins {
> +					pins = "gpio21";
> +					function = "gpio";
> +					drive-strength = <2>;
> +					output-low;

[Severity: Medium]
Does this have the same continuous WAKE# assertion issue as
pcie0_ep_default_state above?

> +				};
> +
> +				clkreq-pins {

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260921-monaco_ep-v1-0-63c5282fb0db@oss.qualcomm.com?part=6

      reply	other threads:[~2026-09-21 11:40 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
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 [this message]

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=20260921114033.644391F000FF@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