Devicetree
 help / color / mirror / Atom feed
* [PATCH] arm64: dts: qcom: qcs6490-rubikpi3: Move PCIe GPIOs to root ports
@ 2026-06-06 19:13 Hongyang Zhao
  2026-06-06 19:30 ` sashiko-bot
  0 siblings, 1 reply; 2+ messages in thread
From: Hongyang Zhao @ 2026-06-06 19:13 UTC (permalink / raw)
  To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley
  Cc: linux-arm-msm, devicetree, linux-kernel, rosh, Hongyang Zhao

The Qualcomm PCIe binding deprecates perst-gpios on the host
bridge and expects endpoint reset GPIOs to be described on the root
port as reset-gpios.

Move the PCIe0 and PCIe1 reset and wake GPIOs to their root port
nodes. This keeps the GPIO ownership with the device below the root
port and matches the PCIe binding.

Signed-off-by: Hongyang Zhao <hongyang.zhao@thundersoft.com>
---
Fix the PCIe reset and wake GPIO description for the Thundercomm
RubikPi3 board.

The board currently describes PERST# and wake GPIOs on the Qualcomm
PCIe host bridge nodes. The Qualcomm PCIe binding deprecates this
and expects endpoint reset GPIOs on the root port nodes as
reset-gpios.

Move the PCIe0 and PCIe1 GPIOs to the corresponding root port
nodes.
---
 .../arm64/boot/dts/qcom/qcs6490-thundercomm-rubikpi3.dts | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/qcs6490-thundercomm-rubikpi3.dts b/arch/arm64/boot/dts/qcom/qcs6490-thundercomm-rubikpi3.dts
index f47efca42d48..5c08ab53cdbd 100644
--- a/arch/arm64/boot/dts/qcom/qcs6490-thundercomm-rubikpi3.dts
+++ b/arch/arm64/boot/dts/qcom/qcs6490-thundercomm-rubikpi3.dts
@@ -812,9 +812,6 @@ &mdss_dsi_phy {
 };
 
 &pcie0 {
-	perst-gpios = <&tlmm 87 GPIO_ACTIVE_LOW>;
-	wake-gpios = <&tlmm 89 GPIO_ACTIVE_HIGH>;
-
 	pinctrl-0 = <&pcie0_clkreq_n>,
 		    <&pcie0_reset_n>,
 		    <&pcie0_wake_n>;
@@ -830,10 +827,12 @@ &pcie0_phy {
 	status = "okay";
 };
 
-&pcie1 {
-	perst-gpios = <&tlmm 2 GPIO_ACTIVE_LOW>;
-	wake-gpios = <&tlmm 3 GPIO_ACTIVE_LOW>;
+&pcie0_port {
+	reset-gpios = <&tlmm 87 GPIO_ACTIVE_LOW>;
+	wake-gpios = <&tlmm 89 GPIO_ACTIVE_HIGH>;
+};
 
+&pcie1 {
 	pinctrl-0 = <&pcie1_clkreq_n>,
 		    <&pcie1_reset_n>,
 		    <&pcie1_wake_n>;
@@ -849,6 +848,11 @@ &pcie1_phy {
 	status = "okay";
 };
 
+&pcie1_port0 {
+	reset-gpios = <&tlmm 2 GPIO_ACTIVE_LOW>;
+	wake-gpios = <&tlmm 3 GPIO_ACTIVE_LOW>;
+};
+
 &pm7325_gpios {
 	kypd_vol_up_n: kypd-vol-up-n-state {
 		pins = "gpio6";

---
base-commit: 6e845bcb78c95af935094040bd4edc3c2b6dd784
change-id: 20260607-rubikpi-bugfix-next-20260605-3c82cae6a7f1

Best regards,
--  
Hongyang Zhao <hongyang.zhao@thundersoft.com>


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH] arm64: dts: qcom: qcs6490-rubikpi3: Move PCIe GPIOs to root ports
  2026-06-06 19:13 [PATCH] arm64: dts: qcom: qcs6490-rubikpi3: Move PCIe GPIOs to root ports Hongyang Zhao
@ 2026-06-06 19:30 ` sashiko-bot
  0 siblings, 0 replies; 2+ messages in thread
From: sashiko-bot @ 2026-06-06 19:30 UTC (permalink / raw)
  To: Hongyang Zhao; +Cc: conor+dt, devicetree, robh

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Moving reset-gpios to the root port node without moving `phys` breaks PCIe reset initialization, leaving the endpoints stuck in reset.
--

commit 061c47f23072e39770a5af921fae6283ad631fb1
Author: Hongyang Zhao <hongyang.zhao@thundersoft.com>

arm64: dts: qcom: qcs6490-rubikpi3: Move PCIe GPIOs to root ports

This commit moves the PCIe0 and PCIe1 reset and wake GPIOs to their
root port nodes in the qcs6490-thundercomm-rubikpi3 device tree. This
keeps the GPIO ownership with the device below the root port to match
the updated PCIe binding expectations.

> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-thundercomm-rubikpi3.dts b/arch/arm64/boot/dts/qcom/qcs6490-thundercomm-rubikpi3.dts
> index f47efca42d48d..5c08ab53cdbd9 100644
> --- a/arch/arm64/boot/dts/qcom/qcs6490-thundercomm-rubikpi3.dts
> +++ b/arch/arm64/boot/dts/qcom/qcs6490-thundercomm-rubikpi3.dts
[ ... ]
> @@ -830,10 +827,12 @@ &pcie0_phy {
>  	status = "okay";
>  };
>  
> -&pcie1 {
> -	perst-gpios = <&tlmm 2 GPIO_ACTIVE_LOW>;
> -	wake-gpios = <&tlmm 3 GPIO_ACTIVE_LOW>;
> +&pcie0_port {
> +	reset-gpios = <&tlmm 87 GPIO_ACTIVE_LOW>;
> +	wake-gpios = <&tlmm 89 GPIO_ACTIVE_HIGH>;
> +};

[Severity: High]
Does moving reset-gpios to the root port node without also moving the
phys property break PCIe reset initialization?

In drivers/pci/controller/dwc/pcie-qcom.c, qcom_pcie_parse_port() expects
to find the phys property on the port node:

qcom_pcie_parse_port() {
        ...
        phy = devm_of_phy_get(dev, node, NULL);
        if (IS_ERR(phy))
                return PTR_ERR(phy);
        ...
}

Because phys remains defined on the host node in the underlying base
dtsi, this returns -ENODEV and falls back to qcom_pcie_parse_legacy_binding().

The legacy parser then looks for perst-gpios on the host node:

qcom_pcie_parse_legacy_binding() {
        ...
        reset = devm_gpiod_get_optional(dev, "perst", GPIOD_OUT_HIGH);
        if (IS_ERR(reset))
                return PTR_ERR(reset);
        ...
}

Since this patch removes perst-gpios from the host node, this silently
returns NULL and the driver proceeds without acquiring the reset GPIO.

With pinctrl configuring the pin as output-low, won't the endpoints remain
stuck in reset indefinitely?

>  
> +&pcie1 {
>  	pinctrl-0 = <&pcie1_clkreq_n>,
>  		    <&pcie1_reset_n>,
>  		    <&pcie1_wake_n>;
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260607-rubikpi-bugfix-next-20260605-v1-1-ff97c5e35bf6@thundersoft.com?part=1

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2026-06-06 19:30 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-06-06 19:13 [PATCH] arm64: dts: qcom: qcs6490-rubikpi3: Move PCIe GPIOs to root ports Hongyang Zhao
2026-06-06 19:30 ` sashiko-bot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox