[PATCH v1 1/1] arm64: dts: qcom: hamoa: Move PCIe PERST and Wake GPIOs to port nodes

[PATCH v1 1/1] arm64: dts: qcom: hamoa: Move PCIe PERST and Wake GPIOs to port nodes

[Ziyue Zhang]

Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
GPIOs to PCIe port nodes and add port Nodes for all PCIe ports") did not
convert all Hamoa‑based platforms to the new method of defining PERST and
Wake GPIOs in the PCIe root port nodes.

Without the change PCIe probe will fail. The probe failure happens because
the PHY stays in the controller node while the PERST/Wake GPIOs were moved
to the port nodes.

This fixes probe failures seen on the following platforms:
 - x1-hp-omnibook-x14
 - x1-microsoft-denali
 - x1e80100-lenovo-yoga-slim7x
 - x1e80100-medion-sprchrgd-14-s1
 - x1p42100-lenovo-thinkbook-16
 - x1-asus-zenbook-a14
 - x1-crd
 - x1-dell-thena

Fixes: 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
---
 .../boot/dts/qcom/x1-asus-zenbook-a14.dtsi    | 16 ++++++++-----
 arch/arm64/boot/dts/qcom/x1-crd.dtsi          | 24 ++++++++++++-------
 arch/arm64/boot/dts/qcom/x1-dell-thena.dtsi   | 14 ++++++-----
 .../boot/dts/qcom/x1-hp-omnibook-x14.dtsi     | 14 ++++++-----
 .../boot/dts/qcom/x1-microsoft-denali.dtsi    |  8 ++++---
 .../dts/qcom/x1e80100-lenovo-yoga-slim7x.dts  |  6 ++---
 .../qcom/x1e80100-medion-sprchrgd-14-s1.dts   | 15 ++++++------
 .../dts/qcom/x1p42100-lenovo-thinkbook-16.dts | 14 ++++++-----
 8 files changed, 65 insertions(+), 46 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/x1-asus-zenbook-a14.dtsi b/arch/arm64/boot/dts/qcom/x1-asus-zenbook-a14.dtsi
index 8e5c5575a532..0a382cc9e643 100644
--- a/arch/arm64/boot/dts/qcom/x1-asus-zenbook-a14.dtsi
+++ b/arch/arm64/boot/dts/qcom/x1-asus-zenbook-a14.dtsi
@@ -1032,9 +1032,6 @@ &mdss_dp3_phy {
 };
 
 &pcie4 {
-	perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
-	wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
-
 	pinctrl-0 = <&pcie4_default>;
 	pinctrl-names = "default";
 
@@ -1048,10 +1045,12 @@ &pcie4_phy {
 	status = "okay";
 };
 
-&pcie6a {
-	perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
-	wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
+&pcie4_port0 {
+	reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
+	wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
+};
 
+&pcie6a {
 	vddpe-3v3-supply = <&vreg_nvme>;
 
 	pinctrl-0 = <&pcie6a_default>;
@@ -1067,6 +1066,11 @@ &pcie6a_phy {
 	status = "okay";
 };
 
+&pcie6a_port0 {
+	reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
+	wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
+};
+
 &pm8550_gpios {
 	rtmr0_default: rtmr0-reset-n-active-state {
 		pins = "gpio10";
diff --git a/arch/arm64/boot/dts/qcom/x1-crd.dtsi b/arch/arm64/boot/dts/qcom/x1-crd.dtsi
index ded96fb43489..2fbf9ec66fb8 100644
--- a/arch/arm64/boot/dts/qcom/x1-crd.dtsi
+++ b/arch/arm64/boot/dts/qcom/x1-crd.dtsi
@@ -1216,15 +1216,17 @@ &mdss_dp3_phy {
 };
 
 &pcie4 {
-	perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
-	wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
-
 	pinctrl-0 = <&pcie4_default>;
 	pinctrl-names = "default";
 
 	status = "okay";
 };
 
+&pcie4_port0 {
+	reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
+	wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
+};
+
 &pcie4_phy {
 	vdda-phy-supply = <&vreg_l3i_0p8>;
 	vdda-pll-supply = <&vreg_l3e_1p2>;
@@ -1233,9 +1235,6 @@ &pcie4_phy {
 };
 
 &pcie5 {
-	perst-gpios = <&tlmm 149 GPIO_ACTIVE_LOW>;
-	wake-gpios = <&tlmm 151 GPIO_ACTIVE_LOW>;
-
 	vddpe-3v3-supply = <&vreg_wwan>;
 
 	pinctrl-0 = <&pcie5_default>;
@@ -1251,10 +1250,12 @@ &pcie5_phy {
 	status = "okay";
 };
 
-&pcie6a {
-	perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
-	wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
+&pcie5_port0 {
+	reset-gpios = <&tlmm 149 GPIO_ACTIVE_LOW>;
+	wake-gpios = <&tlmm 151 GPIO_ACTIVE_LOW>;
+};
 
+&pcie6a {
 	vddpe-3v3-supply = <&vreg_nvme>;
 
 	pinctrl-names = "default";
@@ -1270,6 +1271,11 @@ &pcie6a_phy {
 	status = "okay";
 };
 
+&pcie6a_port0 {
+	reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
+	wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
+};
+
 &pm8550_gpios {
 	kypd_vol_up_n: kypd-vol-up-n-state {
 		pins = "gpio6";
diff --git a/arch/arm64/boot/dts/qcom/x1-dell-thena.dtsi b/arch/arm64/boot/dts/qcom/x1-dell-thena.dtsi
index bf04a12b16bc..217ca8c7d81d 100644
--- a/arch/arm64/boot/dts/qcom/x1-dell-thena.dtsi
+++ b/arch/arm64/boot/dts/qcom/x1-dell-thena.dtsi
@@ -1081,9 +1081,6 @@ &mdss_dp3_phy {
 };
 
 &pcie4 {
-	perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
-	wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
-
 	pinctrl-0 = <&pcie4_default>;
 	pinctrl-names = "default";
 
@@ -1098,6 +1095,9 @@ &pcie4_phy {
 };
 
 &pcie4_port0 {
+	reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
+	wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
+
 	wifi@0 {
 		compatible = "pci17cb,1107";
 		reg = <0x10000 0x0 0x0 0x0 0x0>;
@@ -1115,9 +1115,6 @@ wifi@0 {
 };
 
 &pcie6a {
-	perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
-	wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
-
 	vddpe-3v3-supply = <&vreg_nvme>;
 
 	pinctrl-0 = <&pcie6a_default>;
@@ -1126,6 +1123,11 @@ &pcie6a {
 	status = "okay";
 };
 
+&pcie6a_port0 {
+	reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
+	wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
+};
+
 &pcie6a_phy {
 	vdda-phy-supply = <&vreg_l1d_0p8>;
 	vdda-pll-supply = <&vreg_l2j_1p2>;
diff --git a/arch/arm64/boot/dts/qcom/x1-hp-omnibook-x14.dtsi b/arch/arm64/boot/dts/qcom/x1-hp-omnibook-x14.dtsi
index a4075434162a..41063948c583 100644
--- a/arch/arm64/boot/dts/qcom/x1-hp-omnibook-x14.dtsi
+++ b/arch/arm64/boot/dts/qcom/x1-hp-omnibook-x14.dtsi
@@ -1065,9 +1065,6 @@ &mdss_dp3_phy {
 };
 
 &pcie4 {
-	perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
-	wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
-
 	pinctrl-0 = <&pcie4_default>;
 	pinctrl-names = "default";
 
@@ -1082,6 +1079,9 @@ &pcie4_phy {
 };
 
 &pcie4_port0 {
+	reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
+	wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
+
 	wifi@0 {
 		compatible = "pci17cb,1107";
 		reg = <0x10000 0x0 0x0 0x0 0x0>;
@@ -1099,9 +1099,6 @@ wifi@0 {
 };
 
 &pcie6a {
-	perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
-	wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
-
 	vddpe-3v3-supply = <&vreg_nvme>;
 
 	pinctrl-0 = <&pcie6a_default>;
@@ -1110,6 +1107,11 @@ &pcie6a {
 	status = "okay";
 };
 
+&pcie6a_port0 {
+	reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
+	wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
+};
+
 &pcie6a_phy {
 	vdda-phy-supply = <&vreg_l1d_0p8>;
 	vdda-pll-supply = <&vreg_l2j_1p2>;
diff --git a/arch/arm64/boot/dts/qcom/x1-microsoft-denali.dtsi b/arch/arm64/boot/dts/qcom/x1-microsoft-denali.dtsi
index d77be02848b5..ba6b7b5a9191 100644
--- a/arch/arm64/boot/dts/qcom/x1-microsoft-denali.dtsi
+++ b/arch/arm64/boot/dts/qcom/x1-microsoft-denali.dtsi
@@ -964,9 +964,6 @@ wifi@0 {
 };
 
 &pcie6a {
-	perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
-	wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
-
 	vddpe-3v3-supply = <&vreg_nvme>;
 
 	pinctrl-0 = <&pcie6a_default>;
@@ -982,6 +979,11 @@ &pcie6a_phy {
 	status = "okay";
 };
 
+&pcie6a_port0 {
+	reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
+	wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
+};
+
 &pm8550_gpios {
 	rtmr0_default: rtmr0-reset-n-active-state {
 		pins = "gpio10";
diff --git a/arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts b/arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts
index d6472e5a3f9f..d7938d349205 100644
--- a/arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts
+++ b/arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts
@@ -1126,9 +1126,6 @@ &mdss_dp3_phy {
 };
 
 &pcie4 {
-	perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
-	wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
-
 	pinctrl-0 = <&pcie4_default>;
 	pinctrl-names = "default";
 
@@ -1143,6 +1140,9 @@ &pcie4_phy {
 };
 
 &pcie4_port0 {
+	reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
+	wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
+
 	wifi@0 {
 		compatible = "pci17cb,1107";
 		reg = <0x10000 0x0 0x0 0x0 0x0>;
diff --git a/arch/arm64/boot/dts/qcom/x1e80100-medion-sprchrgd-14-s1.dts b/arch/arm64/boot/dts/qcom/x1e80100-medion-sprchrgd-14-s1.dts
index 20a33e6f27ee..3af7f19224ad 100644
--- a/arch/arm64/boot/dts/qcom/x1e80100-medion-sprchrgd-14-s1.dts
+++ b/arch/arm64/boot/dts/qcom/x1e80100-medion-sprchrgd-14-s1.dts
@@ -1033,9 +1033,6 @@ &mdss_dp3_phy {
 };
 
 &pcie4 {
-	perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
-	wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
-
 	pinctrl-0 = <&pcie4_default>;
 	pinctrl-names = "default";
 
@@ -1050,6 +1047,8 @@ &pcie4_phy {
 };
 
 &pcie4_port0 {
+	reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
+	wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
 	wifi@0 {
 		compatible = "pci17cb,1107";
 		reg = <0x10000 0x0 0x0 0x0 0x0>;
@@ -1067,10 +1066,6 @@ wifi@0 {
 };
 
 &pcie6a {
-	perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
-
-	wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
-
 	vddpe-3v3-supply = <&vreg_nvme>;
 
 	pinctrl-0 = <&pcie6a_default>;
@@ -1086,6 +1081,12 @@ &pcie6a_phy {
 	status = "okay";
 };
 
+&pcie6a_port0 {
+	reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
+	wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
+};
+
+
 &pm8550_gpios {
 	rtmr0_default: rtmr0-reset-n-active-state {
 		pins = "gpio10";
diff --git a/arch/arm64/boot/dts/qcom/x1p42100-lenovo-thinkbook-16.dts b/arch/arm64/boot/dts/qcom/x1p42100-lenovo-thinkbook-16.dts
index 1e5eb8c5dc98..06747b54a38e 100644
--- a/arch/arm64/boot/dts/qcom/x1p42100-lenovo-thinkbook-16.dts
+++ b/arch/arm64/boot/dts/qcom/x1p42100-lenovo-thinkbook-16.dts
@@ -1131,9 +1131,6 @@ &mdss_dp3_phy {
 };
 
 &pcie4 {
-	perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
-	wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
-
 	pinctrl-0 = <&pcie4_default>;
 	pinctrl-names = "default";
 
@@ -1148,6 +1145,9 @@ &pcie4_phy {
 };
 
 &pcie4_port0 {
+	reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
+	wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
+
 	wifi@0 {
 		compatible = "pci17cb,1107";
 		reg = <0x10000 0x0 0x0 0x0 0x0>;
@@ -1165,9 +1165,6 @@ wifi@0 {
 };
 
 &pcie6a {
-	perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
-	wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
-
 	vddpe-3v3-supply = <&vreg_nvme>;
 
 	pinctrl-0 = <&pcie6a_default>;
@@ -1183,6 +1180,11 @@ &pcie6a_phy {
 	status = "okay";
 };
 
+&pcie6a_port0 {
+	reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
+	wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
+};
+
 &pm8550_pwm {
 	status = "okay";
 };
-- 
2.43.0


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v1 1/1] arm64: dts: qcom: hamoa: Move PCIe PERST and Wake GPIOs to port nodes

[Bjorn Helgaas]

On Fri, Mar 13, 2026 at 05:46:18PM +0800, Ziyue Zhang wrote:
> Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
> GPIOs to PCIe port nodes and add port Nodes for all PCIe ports") did not
> convert all Hamoa‑based platforms to the new method of defining PERST and
> Wake GPIOs in the PCIe root port nodes.
> 
> Without the change PCIe probe will fail. The probe failure happens because
> the PHY stays in the controller node while the PERST/Wake GPIOs were moved
> to the port nodes.
> 
> This fixes probe failures seen on the following platforms:
>  - x1-hp-omnibook-x14
>  - x1-microsoft-denali
>  - x1e80100-lenovo-yoga-slim7x
>  - x1e80100-medion-sprchrgd-14-s1
>  - x1p42100-lenovo-thinkbook-16
>  - x1-asus-zenbook-a14
>  - x1-crd
>  - x1-dell-thena
> 
> Fixes: 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")

Are you saying that DTs in the field broke because of some kernel
change?  That's not supposed to happen.  Even though PHY, PERST, and
Wake GPIOs should be described in Root Port nodes instead of the Root
Complex node in *future* DTs, the kernel is still supposed to accept
the old style with them described in the Root Complex node.

If that's the case, the Fixes tag should refer to the driver change
that caused probe to fail with old DTs, and the fix is a driver change
to accept both the old style and the new style.

We can't expect users in the field to update their DTs to match a new
kernel.

Nit: Use PCIe spec nomenclature, e.g., "PERST#" and "WAKE#" in subject
and commit logs.

> Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
> ---
>  .../boot/dts/qcom/x1-asus-zenbook-a14.dtsi    | 16 ++++++++-----
>  arch/arm64/boot/dts/qcom/x1-crd.dtsi          | 24 ++++++++++++-------
>  arch/arm64/boot/dts/qcom/x1-dell-thena.dtsi   | 14 ++++++-----
>  .../boot/dts/qcom/x1-hp-omnibook-x14.dtsi     | 14 ++++++-----
>  .../boot/dts/qcom/x1-microsoft-denali.dtsi    |  8 ++++---
>  .../dts/qcom/x1e80100-lenovo-yoga-slim7x.dts  |  6 ++---
>  .../qcom/x1e80100-medion-sprchrgd-14-s1.dts   | 15 ++++++------
>  .../dts/qcom/x1p42100-lenovo-thinkbook-16.dts | 14 ++++++-----
>  8 files changed, 65 insertions(+), 46 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/x1-asus-zenbook-a14.dtsi b/arch/arm64/boot/dts/qcom/x1-asus-zenbook-a14.dtsi
> index 8e5c5575a532..0a382cc9e643 100644
> --- a/arch/arm64/boot/dts/qcom/x1-asus-zenbook-a14.dtsi
> +++ b/arch/arm64/boot/dts/qcom/x1-asus-zenbook-a14.dtsi
> @@ -1032,9 +1032,6 @@ &mdss_dp3_phy {
>  };
>  
>  &pcie4 {
> -	perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
> -	wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
> -
>  	pinctrl-0 = <&pcie4_default>;
>  	pinctrl-names = "default";
>  
> @@ -1048,10 +1045,12 @@ &pcie4_phy {
>  	status = "okay";
>  };
>  
> -&pcie6a {
> -	perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
> -	wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
> +&pcie4_port0 {
> +	reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
> +	wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
> +};
>  
> +&pcie6a {
>  	vddpe-3v3-supply = <&vreg_nvme>;
>  
>  	pinctrl-0 = <&pcie6a_default>;
> @@ -1067,6 +1066,11 @@ &pcie6a_phy {
>  	status = "okay";
>  };
>  
> +&pcie6a_port0 {
> +	reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
> +	wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
> +};
> +
>  &pm8550_gpios {
>  	rtmr0_default: rtmr0-reset-n-active-state {
>  		pins = "gpio10";
> diff --git a/arch/arm64/boot/dts/qcom/x1-crd.dtsi b/arch/arm64/boot/dts/qcom/x1-crd.dtsi
> index ded96fb43489..2fbf9ec66fb8 100644
> --- a/arch/arm64/boot/dts/qcom/x1-crd.dtsi
> +++ b/arch/arm64/boot/dts/qcom/x1-crd.dtsi
> @@ -1216,15 +1216,17 @@ &mdss_dp3_phy {
>  };
>  
>  &pcie4 {
> -	perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
> -	wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
> -
>  	pinctrl-0 = <&pcie4_default>;
>  	pinctrl-names = "default";
>  
>  	status = "okay";
>  };
>  
> +&pcie4_port0 {
> +	reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
> +	wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
> +};
> +
>  &pcie4_phy {
>  	vdda-phy-supply = <&vreg_l3i_0p8>;
>  	vdda-pll-supply = <&vreg_l3e_1p2>;
> @@ -1233,9 +1235,6 @@ &pcie4_phy {
>  };
>  
>  &pcie5 {
> -	perst-gpios = <&tlmm 149 GPIO_ACTIVE_LOW>;
> -	wake-gpios = <&tlmm 151 GPIO_ACTIVE_LOW>;
> -
>  	vddpe-3v3-supply = <&vreg_wwan>;
>  
>  	pinctrl-0 = <&pcie5_default>;
> @@ -1251,10 +1250,12 @@ &pcie5_phy {
>  	status = "okay";
>  };
>  
> -&pcie6a {
> -	perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
> -	wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
> +&pcie5_port0 {
> +	reset-gpios = <&tlmm 149 GPIO_ACTIVE_LOW>;
> +	wake-gpios = <&tlmm 151 GPIO_ACTIVE_LOW>;
> +};
>  
> +&pcie6a {
>  	vddpe-3v3-supply = <&vreg_nvme>;
>  
>  	pinctrl-names = "default";
> @@ -1270,6 +1271,11 @@ &pcie6a_phy {
>  	status = "okay";
>  };
>  
> +&pcie6a_port0 {
> +	reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
> +	wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
> +};
> +
>  &pm8550_gpios {
>  	kypd_vol_up_n: kypd-vol-up-n-state {
>  		pins = "gpio6";
> diff --git a/arch/arm64/boot/dts/qcom/x1-dell-thena.dtsi b/arch/arm64/boot/dts/qcom/x1-dell-thena.dtsi
> index bf04a12b16bc..217ca8c7d81d 100644
> --- a/arch/arm64/boot/dts/qcom/x1-dell-thena.dtsi
> +++ b/arch/arm64/boot/dts/qcom/x1-dell-thena.dtsi
> @@ -1081,9 +1081,6 @@ &mdss_dp3_phy {
>  };
>  
>  &pcie4 {
> -	perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
> -	wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
> -
>  	pinctrl-0 = <&pcie4_default>;
>  	pinctrl-names = "default";
>  
> @@ -1098,6 +1095,9 @@ &pcie4_phy {
>  };
>  
>  &pcie4_port0 {
> +	reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
> +	wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
> +
>  	wifi@0 {
>  		compatible = "pci17cb,1107";
>  		reg = <0x10000 0x0 0x0 0x0 0x0>;
> @@ -1115,9 +1115,6 @@ wifi@0 {
>  };
>  
>  &pcie6a {
> -	perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
> -	wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
> -
>  	vddpe-3v3-supply = <&vreg_nvme>;
>  
>  	pinctrl-0 = <&pcie6a_default>;
> @@ -1126,6 +1123,11 @@ &pcie6a {
>  	status = "okay";
>  };
>  
> +&pcie6a_port0 {
> +	reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
> +	wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
> +};
> +
>  &pcie6a_phy {
>  	vdda-phy-supply = <&vreg_l1d_0p8>;
>  	vdda-pll-supply = <&vreg_l2j_1p2>;
> diff --git a/arch/arm64/boot/dts/qcom/x1-hp-omnibook-x14.dtsi b/arch/arm64/boot/dts/qcom/x1-hp-omnibook-x14.dtsi
> index a4075434162a..41063948c583 100644
> --- a/arch/arm64/boot/dts/qcom/x1-hp-omnibook-x14.dtsi
> +++ b/arch/arm64/boot/dts/qcom/x1-hp-omnibook-x14.dtsi
> @@ -1065,9 +1065,6 @@ &mdss_dp3_phy {
>  };
>  
>  &pcie4 {
> -	perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
> -	wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
> -
>  	pinctrl-0 = <&pcie4_default>;
>  	pinctrl-names = "default";
>  
> @@ -1082,6 +1079,9 @@ &pcie4_phy {
>  };
>  
>  &pcie4_port0 {
> +	reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
> +	wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
> +
>  	wifi@0 {
>  		compatible = "pci17cb,1107";
>  		reg = <0x10000 0x0 0x0 0x0 0x0>;
> @@ -1099,9 +1099,6 @@ wifi@0 {
>  };
>  
>  &pcie6a {
> -	perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
> -	wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
> -
>  	vddpe-3v3-supply = <&vreg_nvme>;
>  
>  	pinctrl-0 = <&pcie6a_default>;
> @@ -1110,6 +1107,11 @@ &pcie6a {
>  	status = "okay";
>  };
>  
> +&pcie6a_port0 {
> +	reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
> +	wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
> +};
> +
>  &pcie6a_phy {
>  	vdda-phy-supply = <&vreg_l1d_0p8>;
>  	vdda-pll-supply = <&vreg_l2j_1p2>;
> diff --git a/arch/arm64/boot/dts/qcom/x1-microsoft-denali.dtsi b/arch/arm64/boot/dts/qcom/x1-microsoft-denali.dtsi
> index d77be02848b5..ba6b7b5a9191 100644
> --- a/arch/arm64/boot/dts/qcom/x1-microsoft-denali.dtsi
> +++ b/arch/arm64/boot/dts/qcom/x1-microsoft-denali.dtsi
> @@ -964,9 +964,6 @@ wifi@0 {
>  };
>  
>  &pcie6a {
> -	perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
> -	wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
> -
>  	vddpe-3v3-supply = <&vreg_nvme>;
>  
>  	pinctrl-0 = <&pcie6a_default>;
> @@ -982,6 +979,11 @@ &pcie6a_phy {
>  	status = "okay";
>  };
>  
> +&pcie6a_port0 {
> +	reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
> +	wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
> +};
> +
>  &pm8550_gpios {
>  	rtmr0_default: rtmr0-reset-n-active-state {
>  		pins = "gpio10";
> diff --git a/arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts b/arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts
> index d6472e5a3f9f..d7938d349205 100644
> --- a/arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts
> +++ b/arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts
> @@ -1126,9 +1126,6 @@ &mdss_dp3_phy {
>  };
>  
>  &pcie4 {
> -	perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
> -	wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
> -
>  	pinctrl-0 = <&pcie4_default>;
>  	pinctrl-names = "default";
>  
> @@ -1143,6 +1140,9 @@ &pcie4_phy {
>  };
>  
>  &pcie4_port0 {
> +	reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
> +	wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
> +
>  	wifi@0 {
>  		compatible = "pci17cb,1107";
>  		reg = <0x10000 0x0 0x0 0x0 0x0>;
> diff --git a/arch/arm64/boot/dts/qcom/x1e80100-medion-sprchrgd-14-s1.dts b/arch/arm64/boot/dts/qcom/x1e80100-medion-sprchrgd-14-s1.dts
> index 20a33e6f27ee..3af7f19224ad 100644
> --- a/arch/arm64/boot/dts/qcom/x1e80100-medion-sprchrgd-14-s1.dts
> +++ b/arch/arm64/boot/dts/qcom/x1e80100-medion-sprchrgd-14-s1.dts
> @@ -1033,9 +1033,6 @@ &mdss_dp3_phy {
>  };
>  
>  &pcie4 {
> -	perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
> -	wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
> -
>  	pinctrl-0 = <&pcie4_default>;
>  	pinctrl-names = "default";
>  
> @@ -1050,6 +1047,8 @@ &pcie4_phy {
>  };
>  
>  &pcie4_port0 {
> +	reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
> +	wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
>  	wifi@0 {
>  		compatible = "pci17cb,1107";
>  		reg = <0x10000 0x0 0x0 0x0 0x0>;
> @@ -1067,10 +1066,6 @@ wifi@0 {
>  };
>  
>  &pcie6a {
> -	perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
> -
> -	wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
> -
>  	vddpe-3v3-supply = <&vreg_nvme>;
>  
>  	pinctrl-0 = <&pcie6a_default>;
> @@ -1086,6 +1081,12 @@ &pcie6a_phy {
>  	status = "okay";
>  };
>  
> +&pcie6a_port0 {
> +	reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
> +	wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
> +};
> +
> +
>  &pm8550_gpios {
>  	rtmr0_default: rtmr0-reset-n-active-state {
>  		pins = "gpio10";
> diff --git a/arch/arm64/boot/dts/qcom/x1p42100-lenovo-thinkbook-16.dts b/arch/arm64/boot/dts/qcom/x1p42100-lenovo-thinkbook-16.dts
> index 1e5eb8c5dc98..06747b54a38e 100644
> --- a/arch/arm64/boot/dts/qcom/x1p42100-lenovo-thinkbook-16.dts
> +++ b/arch/arm64/boot/dts/qcom/x1p42100-lenovo-thinkbook-16.dts
> @@ -1131,9 +1131,6 @@ &mdss_dp3_phy {
>  };
>  
>  &pcie4 {
> -	perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
> -	wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
> -
>  	pinctrl-0 = <&pcie4_default>;
>  	pinctrl-names = "default";
>  
> @@ -1148,6 +1145,9 @@ &pcie4_phy {
>  };
>  
>  &pcie4_port0 {
> +	reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
> +	wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
> +
>  	wifi@0 {
>  		compatible = "pci17cb,1107";
>  		reg = <0x10000 0x0 0x0 0x0 0x0>;
> @@ -1165,9 +1165,6 @@ wifi@0 {
>  };
>  
>  &pcie6a {
> -	perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
> -	wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
> -
>  	vddpe-3v3-supply = <&vreg_nvme>;
>  
>  	pinctrl-0 = <&pcie6a_default>;
> @@ -1183,6 +1180,11 @@ &pcie6a_phy {
>  	status = "okay";
>  };
>  
> +&pcie6a_port0 {
> +	reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
> +	wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
> +};
> +
>  &pm8550_pwm {
>  	status = "okay";
>  };
> -- 
> 2.43.0
> 

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v1 1/1] arm64: dts: qcom: hamoa: Move PCIe PERST and Wake GPIOs to port nodes

[Manivannan Sadhasivam]

On Fri, Mar 13, 2026 at 11:45:42AM -0500, Bjorn Helgaas wrote:
> On Fri, Mar 13, 2026 at 05:46:18PM +0800, Ziyue Zhang wrote:
> > Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
> > GPIOs to PCIe port nodes and add port Nodes for all PCIe ports") did not
> > convert all Hamoa‑based platforms to the new method of defining PERST and
> > Wake GPIOs in the PCIe root port nodes.
> > 
> > Without the change PCIe probe will fail. The probe failure happens because
> > the PHY stays in the controller node while the PERST/Wake GPIOs were moved
> > to the port nodes.
> > 
> > This fixes probe failures seen on the following platforms:
> >  - x1-hp-omnibook-x14
> >  - x1-microsoft-denali
> >  - x1e80100-lenovo-yoga-slim7x
> >  - x1e80100-medion-sprchrgd-14-s1
> >  - x1p42100-lenovo-thinkbook-16
> >  - x1-asus-zenbook-a14
> >  - x1-crd
> >  - x1-dell-thena
> > 
> > Fixes: 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
> 
> Are you saying that DTs in the field broke because of some kernel
> change?  That's not supposed to happen.  Even though PHY, PERST, and
> Wake GPIOs should be described in Root Port nodes instead of the Root
> Complex node in *future* DTs, the kernel is still supposed to accept
> the old style with them described in the Root Complex node.
> 

This is not related to the driver change. The driver correctly parses all Root
Port properties either in the Root Complex node (old binding) or Root Port node
(new binding). But commit 960609b22be5, left converting mentioned board DTS to
the new binding, leaving those affected platforms in a half baked state i.e.,
some properties in RC node and some in Root Port node. Driver cannot parse such
combinations, so it fails correctly so.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v1 1/1] arm64: dts: qcom: hamoa: Move PCIe PERST and Wake GPIOs to port nodes

[Bjorn Andersson]

On Sat, Mar 14, 2026 at 07:50:50PM +0530, Manivannan Sadhasivam wrote:
> On Fri, Mar 13, 2026 at 11:45:42AM -0500, Bjorn Helgaas wrote:
> > On Fri, Mar 13, 2026 at 05:46:18PM +0800, Ziyue Zhang wrote:
> > > Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
> > > GPIOs to PCIe port nodes and add port Nodes for all PCIe ports") did not
> > > convert all Hamoa‑based platforms to the new method of defining PERST and
> > > Wake GPIOs in the PCIe root port nodes.
> > > 
> > > Without the change PCIe probe will fail. The probe failure happens because
> > > the PHY stays in the controller node while the PERST/Wake GPIOs were moved
> > > to the port nodes.
> > > 
> > > This fixes probe failures seen on the following platforms:
> > >  - x1-hp-omnibook-x14
> > >  - x1-microsoft-denali
> > >  - x1e80100-lenovo-yoga-slim7x
> > >  - x1e80100-medion-sprchrgd-14-s1
> > >  - x1p42100-lenovo-thinkbook-16
> > >  - x1-asus-zenbook-a14
> > >  - x1-crd
> > >  - x1-dell-thena
> > > 
> > > Fixes: 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
> > 
> > Are you saying that DTs in the field broke because of some kernel
> > change?  That's not supposed to happen.  Even though PHY, PERST, and
> > Wake GPIOs should be described in Root Port nodes instead of the Root
> > Complex node in *future* DTs, the kernel is still supposed to accept
> > the old style with them described in the Root Complex node.
> > 
> 
> This is not related to the driver change. The driver correctly parses all Root
> Port properties either in the Root Complex node (old binding) or Root Port node
> (new binding). But commit 960609b22be5, left converting mentioned board DTS to
> the new binding, leaving those affected platforms in a half baked state i.e.,
> some properties in RC node and some in Root Port node. Driver cannot parse such
> combinations, so it fails correctly so.
> 

Are you saying that above listed machines has broken PCIe support in
v7.0-rc?

It seems this is a (partial) revert of 960609b22be5, is this actually
fixing that change, or is it only applicable once some other changes are
applied?

Where should this be merged?

Regards,
Bjorn

> - Mani
> 
> -- 
> மணிவண்ணன் சதாசிவம்

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v1 1/1] arm64: dts: qcom: hamoa: Move PCIe PERST and Wake GPIOs to port nodes

[Manivannan Sadhasivam]

On Sun, Mar 15, 2026 at 09:53:33PM -0500, Bjorn Andersson wrote:
> On Sat, Mar 14, 2026 at 07:50:50PM +0530, Manivannan Sadhasivam wrote:
> > On Fri, Mar 13, 2026 at 11:45:42AM -0500, Bjorn Helgaas wrote:
> > > On Fri, Mar 13, 2026 at 05:46:18PM +0800, Ziyue Zhang wrote:
> > > > Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
> > > > GPIOs to PCIe port nodes and add port Nodes for all PCIe ports") did not
> > > > convert all Hamoa‑based platforms to the new method of defining PERST and
> > > > Wake GPIOs in the PCIe root port nodes.
> > > > 
> > > > Without the change PCIe probe will fail. The probe failure happens because
> > > > the PHY stays in the controller node while the PERST/Wake GPIOs were moved
> > > > to the port nodes.
> > > > 
> > > > This fixes probe failures seen on the following platforms:
> > > >  - x1-hp-omnibook-x14
> > > >  - x1-microsoft-denali
> > > >  - x1e80100-lenovo-yoga-slim7x
> > > >  - x1e80100-medion-sprchrgd-14-s1
> > > >  - x1p42100-lenovo-thinkbook-16
> > > >  - x1-asus-zenbook-a14
> > > >  - x1-crd
> > > >  - x1-dell-thena
> > > > 
> > > > Fixes: 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
> > > 
> > > Are you saying that DTs in the field broke because of some kernel
> > > change?  That's not supposed to happen.  Even though PHY, PERST, and
> > > Wake GPIOs should be described in Root Port nodes instead of the Root
> > > Complex node in *future* DTs, the kernel is still supposed to accept
> > > the old style with them described in the Root Complex node.
> > > 
> > 
> > This is not related to the driver change. The driver correctly parses all Root
> > Port properties either in the Root Complex node (old binding) or Root Port node
> > (new binding). But commit 960609b22be5, left converting mentioned board DTS to
> > the new binding, leaving those affected platforms in a half baked state i.e.,
> > some properties in RC node and some in Root Port node. Driver cannot parse such
> > combinations, so it fails correctly so.
> > 
> 
> Are you saying that above listed machines has broken PCIe support in
> v7.0-rc?
> 

I haven't verified it, but I'm pretty sure PCIe is broken on these platforms.

> It seems this is a (partial) revert of 960609b22be5, is this actually
> fixing that change, or is it only applicable once some other changes are
> applied?
> 

This change is fixing the issue in the respective board DTS and is a standalone
fix on top of v7.0-rc1.

> Where should this be merged?
> 

Qcom tree for 7.0-rcX.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v1 1/1] arm64: dts: qcom: hamoa: Move PCIe PERST and Wake GPIOs to port nodes

[Konrad Dybcio]

On 3/13/26 10:46 AM, Ziyue Zhang wrote:
> Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
> GPIOs to PCIe port nodes and add port Nodes for all PCIe ports") did not
> convert all Hamoa‑based platforms to the new method of defining PERST and
> Wake GPIOs in the PCIe root port nodes.
> 
> Without the change PCIe probe will fail. The probe failure happens because
> the PHY stays in the controller node while the PERST/Wake GPIOs were moved
> to the port nodes.
> 
> This fixes probe failures seen on the following platforms:
>  - x1-hp-omnibook-x14
>  - x1-microsoft-denali
>  - x1e80100-lenovo-yoga-slim7x
>  - x1e80100-medion-sprchrgd-14-s1
>  - x1p42100-lenovo-thinkbook-16
>  - x1-asus-zenbook-a14
>  - x1-crd
>  - x1-dell-thena
> 
> Fixes: 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
> Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v1 1/1] arm64: dts: qcom: hamoa: Move PCIe PERST and Wake GPIOs to port nodes

[Bjorn Helgaas]

On Sat, Mar 14, 2026 at 07:50:50PM +0530, Manivannan Sadhasivam wrote:
> On Fri, Mar 13, 2026 at 11:45:42AM -0500, Bjorn Helgaas wrote:
> > On Fri, Mar 13, 2026 at 05:46:18PM +0800, Ziyue Zhang wrote:
> > > Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
> > > GPIOs to PCIe port nodes and add port Nodes for all PCIe ports") did not
> > > convert all Hamoa‑based platforms to the new method of defining PERST and
> > > Wake GPIOs in the PCIe root port nodes.
> > > 
> > > Without the change PCIe probe will fail. The probe failure happens because
> > > the PHY stays in the controller node while the PERST/Wake GPIOs were moved
> > > to the port nodes.
> > > 
> > > This fixes probe failures seen on the following platforms:
> > >  - x1-hp-omnibook-x14
> > >  - x1-microsoft-denali
> > >  - x1e80100-lenovo-yoga-slim7x
> > >  - x1e80100-medion-sprchrgd-14-s1
> > >  - x1p42100-lenovo-thinkbook-16
> > >  - x1-asus-zenbook-a14
> > >  - x1-crd
> > >  - x1-dell-thena
> > > 
> > > Fixes: 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
> > 
> > Are you saying that DTs in the field broke because of some kernel
> > change?  That's not supposed to happen.  Even though PHY, PERST, and
> > Wake GPIOs should be described in Root Port nodes instead of the Root
> > Complex node in *future* DTs, the kernel is still supposed to accept
> > the old style with them described in the Root Complex node.
> 
> This is not related to the driver change. The driver correctly
> parses all Root Port properties either in the Root Complex node (old
> binding) or Root Port node (new binding). But commit 960609b22be5,
> left converting mentioned board DTS to the new binding, leaving
> those affected platforms in a half baked state i.e., some properties
> in RC node and some in Root Port node. Driver cannot parse such
> combinations, so it fails correctly so.

The commit log mentions probe failures on some machines.  I'd like it
to be more clear about who is affected and what they need to do to fix
their machines.  If it only affects developers who generated DTs based
on 960609b22be5 for internal testing, we should say that so it's clear
that no end users will see any regressions or boot failures.

Is there some way to verify that after this patch, none of the
generated DTBs are in this half-baked situation?  Some kind of
automated DTB checker?

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v1 1/1] arm64: dts: qcom: hamoa: Move PCIe PERST and Wake GPIOs to port nodes

[Bjorn Andersson]

On Mon, Mar 16, 2026 at 08:50:12AM +0530, Manivannan Sadhasivam wrote:
> On Sun, Mar 15, 2026 at 09:53:33PM -0500, Bjorn Andersson wrote:
> > On Sat, Mar 14, 2026 at 07:50:50PM +0530, Manivannan Sadhasivam wrote:
> > > On Fri, Mar 13, 2026 at 11:45:42AM -0500, Bjorn Helgaas wrote:
> > > > On Fri, Mar 13, 2026 at 05:46:18PM +0800, Ziyue Zhang wrote:
> > > > > Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
> > > > > GPIOs to PCIe port nodes and add port Nodes for all PCIe ports") did not
> > > > > convert all Hamoa‑based platforms to the new method of defining PERST and
> > > > > Wake GPIOs in the PCIe root port nodes.
> > > > > 
> > > > > Without the change PCIe probe will fail. The probe failure happens because
> > > > > the PHY stays in the controller node while the PERST/Wake GPIOs were moved
> > > > > to the port nodes.
> > > > > 
> > > > > This fixes probe failures seen on the following platforms:
> > > > >  - x1-hp-omnibook-x14
> > > > >  - x1-microsoft-denali
> > > > >  - x1e80100-lenovo-yoga-slim7x
> > > > >  - x1e80100-medion-sprchrgd-14-s1
> > > > >  - x1p42100-lenovo-thinkbook-16
> > > > >  - x1-asus-zenbook-a14
> > > > >  - x1-crd
> > > > >  - x1-dell-thena
> > > > > 
> > > > > Fixes: 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
> > > > 
> > > > Are you saying that DTs in the field broke because of some kernel
> > > > change?  That's not supposed to happen.  Even though PHY, PERST, and
> > > > Wake GPIOs should be described in Root Port nodes instead of the Root
> > > > Complex node in *future* DTs, the kernel is still supposed to accept
> > > > the old style with them described in the Root Complex node.
> > > > 
> > > 
> > > This is not related to the driver change. The driver correctly parses all Root
> > > Port properties either in the Root Complex node (old binding) or Root Port node
> > > (new binding). But commit 960609b22be5, left converting mentioned board DTS to
> > > the new binding, leaving those affected platforms in a half baked state i.e.,
> > > some properties in RC node and some in Root Port node. Driver cannot parse such
> > > combinations, so it fails correctly so.
> > > 
> > 
> > Are you saying that above listed machines has broken PCIe support in
> > v7.0-rc?
> > 
> 
> I haven't verified it, but I'm pretty sure PCIe is broken on these platforms.
> 

In line with Bjorn's request, we shouldn't have to guess.

> > It seems this is a (partial) revert of 960609b22be5, is this actually
> > fixing that change, or is it only applicable once some other changes are
> > applied?
> > 
> 
> This change is fixing the issue in the respective board DTS and is a standalone
> fix on top of v7.0-rc1.
> 

So 960609b22be5 was broken when I merged it?

The commit message says that the commit was incomplete, in that it
didn't fully convert from the old to the new style, so it sounds like
the offending commit was incomplete - but I believe the offending commit
was a workaround for the new solution not being in place and this commit
mostly reverts the changes in the offending commit.

In other words, it's not clear to me, from the commit message, why this
change is a -rc fix. Perhaps the author of the offending commit tricked
me to merge that one, and that's what's being fixed?

Also, is the lack of Tested-by telling us that nobody has tested any of
the v7.0-rc on the 8 listed Hamoa devices?



If it's actually needed, can we please have the commit message improved
so that we can merge it into -rc?

Regards,
Bjorn

> > Where should this be merged?
> > 
> 
> Qcom tree for 7.0-rcX.
> 
> - Mani
> 
> -- 
> மணிவண்ணன் சதாசிவம்

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v1 1/1] arm64: dts: qcom: hamoa: Move PCIe PERST and Wake GPIOs to port nodes

[Manivannan Sadhasivam]

On Tue, Mar 17, 2026 at 12:13:19PM -0500, Bjorn Helgaas wrote:
> On Sat, Mar 14, 2026 at 07:50:50PM +0530, Manivannan Sadhasivam wrote:
> > On Fri, Mar 13, 2026 at 11:45:42AM -0500, Bjorn Helgaas wrote:
> > > On Fri, Mar 13, 2026 at 05:46:18PM +0800, Ziyue Zhang wrote:
> > > > Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
> > > > GPIOs to PCIe port nodes and add port Nodes for all PCIe ports") did not
> > > > convert all Hamoa‑based platforms to the new method of defining PERST and
> > > > Wake GPIOs in the PCIe root port nodes.
> > > > 
> > > > Without the change PCIe probe will fail. The probe failure happens because
> > > > the PHY stays in the controller node while the PERST/Wake GPIOs were moved
> > > > to the port nodes.
> > > > 
> > > > This fixes probe failures seen on the following platforms:
> > > >  - x1-hp-omnibook-x14
> > > >  - x1-microsoft-denali
> > > >  - x1e80100-lenovo-yoga-slim7x
> > > >  - x1e80100-medion-sprchrgd-14-s1
> > > >  - x1p42100-lenovo-thinkbook-16
> > > >  - x1-asus-zenbook-a14
> > > >  - x1-crd
> > > >  - x1-dell-thena
> > > > 
> > > > Fixes: 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
> > > 
> > > Are you saying that DTs in the field broke because of some kernel
> > > change?  That's not supposed to happen.  Even though PHY, PERST, and
> > > Wake GPIOs should be described in Root Port nodes instead of the Root
> > > Complex node in *future* DTs, the kernel is still supposed to accept
> > > the old style with them described in the Root Complex node.
> > 
> > This is not related to the driver change. The driver correctly
> > parses all Root Port properties either in the Root Complex node (old
> > binding) or Root Port node (new binding). But commit 960609b22be5,
> > left converting mentioned board DTS to the new binding, leaving
> > those affected platforms in a half baked state i.e., some properties
> > in RC node and some in Root Port node. Driver cannot parse such
> > combinations, so it fails correctly so.
> 
> The commit log mentions probe failures on some machines.  I'd like it
> to be more clear about who is affected and what they need to do to fix
> their machines.

There is already a list of affected machines mentioned in the commit message.

And for fix, they just need to apply this patch. Or once this patch gets merged
into v7.0-rcS, v7.0 will have no issue.

>  If it only affects developers who generated DTs based
> on 960609b22be5 for internal testing, we should say that so it's clear
> that no end users will see any regressions or boot failures.
> 

Whoever have included commit 960609b22be5 in their kernel and using the above
mentioned machines will see the failure. But looks like no one really tested
v7.0-rcS on these machines as we haven't gotten any reports so far.

> Is there some way to verify that after this patch, none of the
> generated DTBs are in this half-baked situation?  Some kind of
> automated DTB checker?

I sent out a DT binding series [1] that was supposed to catch these issues
during DTB validation phase, but unfortunately it got stuck in the review. I'll
try to stir things up.

- Mani

[1] https://lore.kernel.org/linux-pci/20251106-pci-binding-v2-0-bebe9345fc4b@oss.qualcomm.com
-- 
மணிவண்ணன் சதாசிவம்

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v1 1/1] arm64: dts: qcom: hamoa: Move PCIe PERST and Wake GPIOs to port nodes

[Manivannan Sadhasivam]

On Wed, Mar 18, 2026 at 09:42:56PM -0500, Bjorn Andersson wrote:
> On Mon, Mar 16, 2026 at 08:50:12AM +0530, Manivannan Sadhasivam wrote:
> > On Sun, Mar 15, 2026 at 09:53:33PM -0500, Bjorn Andersson wrote:
> > > On Sat, Mar 14, 2026 at 07:50:50PM +0530, Manivannan Sadhasivam wrote:
> > > > On Fri, Mar 13, 2026 at 11:45:42AM -0500, Bjorn Helgaas wrote:
> > > > > On Fri, Mar 13, 2026 at 05:46:18PM +0800, Ziyue Zhang wrote:
> > > > > > Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
> > > > > > GPIOs to PCIe port nodes and add port Nodes for all PCIe ports") did not
> > > > > > convert all Hamoa‑based platforms to the new method of defining PERST and
> > > > > > Wake GPIOs in the PCIe root port nodes.
> > > > > > 
> > > > > > Without the change PCIe probe will fail. The probe failure happens because
> > > > > > the PHY stays in the controller node while the PERST/Wake GPIOs were moved
> > > > > > to the port nodes.
> > > > > > 
> > > > > > This fixes probe failures seen on the following platforms:
> > > > > >  - x1-hp-omnibook-x14
> > > > > >  - x1-microsoft-denali
> > > > > >  - x1e80100-lenovo-yoga-slim7x
> > > > > >  - x1e80100-medion-sprchrgd-14-s1
> > > > > >  - x1p42100-lenovo-thinkbook-16
> > > > > >  - x1-asus-zenbook-a14
> > > > > >  - x1-crd
> > > > > >  - x1-dell-thena
> > > > > > 
> > > > > > Fixes: 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
> > > > > 
> > > > > Are you saying that DTs in the field broke because of some kernel
> > > > > change?  That's not supposed to happen.  Even though PHY, PERST, and
> > > > > Wake GPIOs should be described in Root Port nodes instead of the Root
> > > > > Complex node in *future* DTs, the kernel is still supposed to accept
> > > > > the old style with them described in the Root Complex node.
> > > > > 
> > > > 
> > > > This is not related to the driver change. The driver correctly parses all Root
> > > > Port properties either in the Root Complex node (old binding) or Root Port node
> > > > (new binding). But commit 960609b22be5, left converting mentioned board DTS to
> > > > the new binding, leaving those affected platforms in a half baked state i.e.,
> > > > some properties in RC node and some in Root Port node. Driver cannot parse such
> > > > combinations, so it fails correctly so.
> > > > 
> > > 
> > > Are you saying that above listed machines has broken PCIe support in
> > > v7.0-rc?
> > > 
> > 
> > I haven't verified it, but I'm pretty sure PCIe is broken on these platforms.
> > 
> 
> In line with Bjorn's request, we shouldn't have to guess.
> 
> > > It seems this is a (partial) revert of 960609b22be5, is this actually
> > > fixing that change, or is it only applicable once some other changes are
> > > applied?
> > > 
> > 
> > This change is fixing the issue in the respective board DTS and is a standalone
> > fix on top of v7.0-rc1.
> > 
> 
> So 960609b22be5 was broken when I merged it?
> 

Broken on the machines mentioned in the commit message, not for all Hamoa
platforms.

> The commit message says that the commit was incomplete, in that it
> didn't fully convert from the old to the new style, so it sounds like
> the offending commit was incomplete - but I believe the offending commit
> was a workaround for the new solution not being in place and this commit
> mostly reverts the changes in the offending commit.
> 

So 960609b22be5 was supposed to move all the platforms from old PCIe binding to
new for greater good, but it apparently decided to do so only for a subset of
the platforms for some reason which  don't know. But the problem arises due to
960609b22be5 changing the hamoa.dtsi to the new binding which also warrants the
platform DTS to also be changed to the new binding. If we only have either dtsi
or dts converted and not both to the new binding, the driver will get confused
and fail. And this is what exactly happended for below machines:

 - x1-hp-omnibook-x14
 - x1-microsoft-denali
 - x1e80100-lenovo-yoga-slim7x
 - x1e80100-medion-sprchrgd-14-s1
 - x1p42100-lenovo-thinkbook-16
 - x1-asus-zenbook-a14
 - x1-crd
 - x1-dell-thena

> In other words, it's not clear to me, from the commit message, why this
> change is a -rc fix. Perhaps the author of the offending commit tricked
> me to merge that one, and that's what's being fixed?
> 

I wouldn't say that the author has tricked, but he was unaware of the fact that
changing SoC dtsi warrants change in all platforms, not a subset. I wanted to
catch these kind of issues with DT binding validation, so I sent out a series
earlier [1], but it got stuck. I'll push it forward.

[1] https://lore.kernel.org/linux-pci/20251106-pci-binding-v2-0-bebe9345fc4b@oss.qualcomm.com

> Also, is the lack of Tested-by telling us that nobody has tested any of
> the v7.0-rc on the 8 listed Hamoa devices?
> 

Exactly. Otherwise, they would've seen the failure so obviously.

> 
> 
> If it's actually needed, can we please have the commit message improved
> so that we can merge it into -rc?
> 

Sure. I'll work with Ziyue to reword it properly.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v1 1/1] arm64: dts: qcom: hamoa: Move PCIe PERST and Wake GPIOs to port nodes

[Krzysztof Kozlowski]

On 19/03/2026 06:28, Manivannan Sadhasivam wrote:
>>  If it only affects developers who generated DTs based
>> on 960609b22be5 for internal testing, we should say that so it's clear
>> that no end users will see any regressions or boot failures.
>>
> 
> Whoever have included commit 960609b22be5 in their kernel and using the above
> mentioned machines will see the failure. But looks like no one really tested
> v7.0-rcS on these machines as we haven't gotten any reports so far.
> 
>> Is there some way to verify that after this patch, none of the
>> generated DTBs are in this half-baked situation?  Some kind of
>> automated DTB checker?
> 
> I sent out a DT binding series [1] that was supposed to catch these issues
> during DTB validation phase, but unfortunately it got stuck in the review. I'll
> try to stir things up.
> 

What about other projects which use this DTB directly (e.g. OpenBSD)?
Are they considered broken with 960609b22be5?

Best regards,
Krzysztof

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v1 1/1] arm64: dts: qcom: hamoa: Move PCIe PERST and Wake GPIOs to port nodes

[Tobias Heider]

Resending because the previous mail ended up being HTML (sorry)

On Thu, Mar 19, 2026 at 6:39 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
>
> On Wed, Mar 18, 2026 at 09:42:56PM -0500, Bjorn Andersson wrote:
> > On Mon, Mar 16, 2026 at 08:50:12AM +0530, Manivannan Sadhasivam wrote:
> > > On Sun, Mar 15, 2026 at 09:53:33PM -0500, Bjorn Andersson wrote:
> > > > On Sat, Mar 14, 2026 at 07:50:50PM +0530, Manivannan Sadhasivam wrote:
> > > > > On Fri, Mar 13, 2026 at 11:45:42AM -0500, Bjorn Helgaas wrote:
> > > > > > On Fri, Mar 13, 2026 at 05:46:18PM +0800, Ziyue Zhang wrote:
> > > > > > > Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
> > > > > > > GPIOs to PCIe port nodes and add port Nodes for all PCIe ports") did not
> > > > > > > convert all Hamoa‑based platforms to the new method of defining PERST and
> > > > > > > Wake GPIOs in the PCIe root port nodes.
> > > > > > >
> > > > > > > Without the change PCIe probe will fail. The probe failure happens because
> > > > > > > the PHY stays in the controller node while the PERST/Wake GPIOs were moved
> > > > > > > to the port nodes.
> > > > > > >
> > > > > > > This fixes probe failures seen on the following platforms:
> > > > > > >  - x1-hp-omnibook-x14
> > > > > > >  - x1-microsoft-denali
> > > > > > >  - x1e80100-lenovo-yoga-slim7x
> > > > > > >  - x1e80100-medion-sprchrgd-14-s1
> > > > > > >  - x1p42100-lenovo-thinkbook-16
> > > > > > >  - x1-asus-zenbook-a14
> > > > > > >  - x1-crd
> > > > > > >  - x1-dell-thena
> > > > > > >
> > > > > > > Fixes: 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
> > > > > >
> > > > > > Are you saying that DTs in the field broke because of some kernel
> > > > > > change?  That's not supposed to happen.  Even though PHY, PERST, and
> > > > > > Wake GPIOs should be described in Root Port nodes instead of the Root
> > > > > > Complex node in *future* DTs, the kernel is still supposed to accept
> > > > > > the old style with them described in the Root Complex node.
> > > > > >
> > > > >
> > > > > This is not related to the driver change. The driver correctly parses all Root
> > > > > Port properties either in the Root Complex node (old binding) or Root Port node
> > > > > (new binding). But commit 960609b22be5, left converting mentioned board DTS to
> > > > > the new binding, leaving those affected platforms in a half baked state i.e.,
> > > > > some properties in RC node and some in Root Port node. Driver cannot parse such
> > > > > combinations, so it fails correctly so.
> > > > >
> > > >
> > > > Are you saying that above listed machines has broken PCIe support in
> > > > v7.0-rc?
> > > >
> > >
> > > I haven't verified it, but I'm pretty sure PCIe is broken on these platforms.
> > >
> >
> > In line with Bjorn's request, we shouldn't have to guess.
> >
> > > > It seems this is a (partial) revert of 960609b22be5, is this actually
> > > > fixing that change, or is it only applicable once some other changes are
> > > > applied?
> > > >
> > >
> > > This change is fixing the issue in the respective board DTS and is a standalone
> > > fix on top of v7.0-rc1.
> > >
> >
> > So 960609b22be5 was broken when I merged it?
> >
>
> Broken on the machines mentioned in the commit message, not for all Hamoa
> platforms.
>
> > The commit message says that the commit was incomplete, in that it
> > didn't fully convert from the old to the new style, so it sounds like
> > the offending commit was incomplete - but I believe the offending commit
> > was a workaround for the new solution not being in place and this commit
> > mostly reverts the changes in the offending commit.
> >
>
> So 960609b22be5 was supposed to move all the platforms from old PCIe binding to
> new for greater good, but it apparently decided to do so only for a subset of
> the platforms for some reason which  don't know. But the problem arises due to
> 960609b22be5 changing the hamoa.dtsi to the new binding which also warrants the
> platform DTS to also be changed to the new binding. If we only have either dtsi
> or dts converted and not both to the new binding, the driver will get confused
> and fail. And this is what exactly happended for below machines:
>
>  - x1-hp-omnibook-x14
>  - x1-microsoft-denali
>  - x1e80100-lenovo-yoga-slim7x
>  - x1e80100-medion-sprchrgd-14-s1
>  - x1p42100-lenovo-thinkbook-16
>  - x1-asus-zenbook-a14
>  - x1-crd
>  - x1-dell-thena

I can confirm the breakage for (some of) the listed devices on Ubuntu.
We are experimenting with 7.0-rcs ahead of our 26.04 release.

I'll try to collect some test feedback for the fix.
I'd certainly appreciate this being included as an rc fix since
currently half of
the x1 laptop devices are broken.

>
> > In other words, it's not clear to me, from the commit message, why this
> > change is a -rc fix. Perhaps the author of the offending commit tricked
> > me to merge that one, and that's what's being fixed?
> >
>
> I wouldn't say that the author has tricked, but he was unaware of the fact that
> changing SoC dtsi warrants change in all platforms, not a subset. I wanted to
> catch these kind of issues with DT binding validation, so I sent out a series
> earlier [1], but it got stuck. I'll push it forward.
>
> [1] https://lore.kernel.org/linux-pci/20251106-pci-binding-v2-0-bebe9345fc4b@oss.qualcomm.com
>
> > Also, is the lack of Tested-by telling us that nobody has tested any of
> > the v7.0-rc on the 8 listed Hamoa devices?
> >
>
> Exactly. Otherwise, they would've seen the failure so obviously.
>
> >
> >
> > If it's actually needed, can we please have the commit message improved
> > so that we can merge it into -rc?
> >
>
> Sure. I'll work with Ziyue to reword it properly.
>
> - Mani
>
> --
> மணிவண்ணன் சதாசிவம்
>

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v1 1/1] arm64: dts: qcom: hamoa: Move PCIe PERST and Wake GPIOs to port nodes

[Bjorn Helgaas]

On Thu, Mar 19, 2026 at 10:58:36AM +0530, Manivannan Sadhasivam wrote:
> On Tue, Mar 17, 2026 at 12:13:19PM -0500, Bjorn Helgaas wrote:
> > On Sat, Mar 14, 2026 at 07:50:50PM +0530, Manivannan Sadhasivam wrote:
> > > On Fri, Mar 13, 2026 at 11:45:42AM -0500, Bjorn Helgaas wrote:
> > > > On Fri, Mar 13, 2026 at 05:46:18PM +0800, Ziyue Zhang wrote:
> > > > > Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
> > > > > GPIOs to PCIe port nodes and add port Nodes for all PCIe ports") did not
> > > > > convert all Hamoa‑based platforms to the new method of defining PERST and
> > > > > Wake GPIOs in the PCIe root port nodes.
> > > > > 
> > > > > Without the change PCIe probe will fail. The probe failure happens because
> > > > > the PHY stays in the controller node while the PERST/Wake GPIOs were moved
> > > > > to the port nodes.
> > > > > 
> > > > > This fixes probe failures seen on the following platforms:
> > > > >  - x1-hp-omnibook-x14
> > > > >  - x1-microsoft-denali
> > > > >  - x1e80100-lenovo-yoga-slim7x
> > > > >  - x1e80100-medion-sprchrgd-14-s1
> > > > >  - x1p42100-lenovo-thinkbook-16
> > > > >  - x1-asus-zenbook-a14
> > > > >  - x1-crd
> > > > >  - x1-dell-thena
> > > > > 
> > > > > Fixes: 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
> > > > 
> > > > Are you saying that DTs in the field broke because of some kernel
> > > > change?  That's not supposed to happen.  Even though PHY, PERST, and
> > > > Wake GPIOs should be described in Root Port nodes instead of the Root
> > > > Complex node in *future* DTs, the kernel is still supposed to accept
> > > > the old style with them described in the Root Complex node.
> > > 
> > > This is not related to the driver change. The driver correctly
> > > parses all Root Port properties either in the Root Complex node (old
> > > binding) or Root Port node (new binding). But commit 960609b22be5,
> > > left converting mentioned board DTS to the new binding, leaving
> > > those affected platforms in a half baked state i.e., some properties
> > > in RC node and some in Root Port node. Driver cannot parse such
> > > combinations, so it fails correctly so.
> > 
> > The commit log mentions probe failures on some machines.  I'd like it
> > to be more clear about who is affected and what they need to do to fix
> > their machines.
> 
> There is already a list of affected machines mentioned in the commit
> message.
>
> And for fix, they just need to apply this patch. Or once this patch
> gets merged into v7.0-rcS, v7.0 will have no issue.
>
> >  If it only affects developers who generated DTs based on
> >  960609b22be5 for internal testing, we should say that so it's
> >  clear that no end users will see any regressions or boot
> >  failures.
> 
> Whoever have included commit 960609b22be5 in their kernel and using
> the above mentioned machines will see the failure. But looks like no
> one really tested v7.0-rcS on these machines as we haven't gotten
> any reports so far.

Two points:

  - a2fbecdbbb9d ("PCI: qcom: Add support for parsing the new Root
    Port binding") is intended for hardware with multiple Root Ports
    with independent PHY/reset controls.

    The driver will always fall back to PHY/reset info in the host
    bridge, so I think the only reason to do 960609b22be5 and this fix
    is if hamoa.dtsi will also be used for hardware with multiple Root
    Ports.  If there's no plan for multiple RPs with hamoa.dtsi,
    reverting 960609b22be5 is another, less risky, option.

  - 960609b22be5 only touches .dtsi and .dts files; it doesn't change
    the kernel itself.

    So I assume this issue only affects somebody who used v7.0-rc1 to
    rebuild the DTB for one of those machines and then installed that
    new DTB on their system.  That sounds like developers to me, not
    end users.

    The commit log already mentions the affected machines.  I'm
    suggesting that it should also say something about the fact that
    only DTBs built with 960609b22be5 are affected, i.e., DTBs built
    with 960609b22be5 but without this fix are incompatible with the
    kernel driver.

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v1 1/1] arm64: dts: qcom: hamoa: Move PCIe PERST and Wake GPIOs to port nodes

[Manivannan Sadhasivam]

On Thu, Mar 19, 2026 at 12:17:28PM -0500, Bjorn Helgaas wrote:
> On Thu, Mar 19, 2026 at 10:58:36AM +0530, Manivannan Sadhasivam wrote:
> > On Tue, Mar 17, 2026 at 12:13:19PM -0500, Bjorn Helgaas wrote:
> > > On Sat, Mar 14, 2026 at 07:50:50PM +0530, Manivannan Sadhasivam wrote:
> > > > On Fri, Mar 13, 2026 at 11:45:42AM -0500, Bjorn Helgaas wrote:
> > > > > On Fri, Mar 13, 2026 at 05:46:18PM +0800, Ziyue Zhang wrote:
> > > > > > Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
> > > > > > GPIOs to PCIe port nodes and add port Nodes for all PCIe ports") did not
> > > > > > convert all Hamoa‑based platforms to the new method of defining PERST and
> > > > > > Wake GPIOs in the PCIe root port nodes.
> > > > > > 
> > > > > > Without the change PCIe probe will fail. The probe failure happens because
> > > > > > the PHY stays in the controller node while the PERST/Wake GPIOs were moved
> > > > > > to the port nodes.
> > > > > > 
> > > > > > This fixes probe failures seen on the following platforms:
> > > > > >  - x1-hp-omnibook-x14
> > > > > >  - x1-microsoft-denali
> > > > > >  - x1e80100-lenovo-yoga-slim7x
> > > > > >  - x1e80100-medion-sprchrgd-14-s1
> > > > > >  - x1p42100-lenovo-thinkbook-16
> > > > > >  - x1-asus-zenbook-a14
> > > > > >  - x1-crd
> > > > > >  - x1-dell-thena
> > > > > > 
> > > > > > Fixes: 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
> > > > > 
> > > > > Are you saying that DTs in the field broke because of some kernel
> > > > > change?  That's not supposed to happen.  Even though PHY, PERST, and
> > > > > Wake GPIOs should be described in Root Port nodes instead of the Root
> > > > > Complex node in *future* DTs, the kernel is still supposed to accept
> > > > > the old style with them described in the Root Complex node.
> > > > 
> > > > This is not related to the driver change. The driver correctly
> > > > parses all Root Port properties either in the Root Complex node (old
> > > > binding) or Root Port node (new binding). But commit 960609b22be5,
> > > > left converting mentioned board DTS to the new binding, leaving
> > > > those affected platforms in a half baked state i.e., some properties
> > > > in RC node and some in Root Port node. Driver cannot parse such
> > > > combinations, so it fails correctly so.
> > > 
> > > The commit log mentions probe failures on some machines.  I'd like it
> > > to be more clear about who is affected and what they need to do to fix
> > > their machines.
> > 
> > There is already a list of affected machines mentioned in the commit
> > message.
> >
> > And for fix, they just need to apply this patch. Or once this patch
> > gets merged into v7.0-rcS, v7.0 will have no issue.
> >
> > >  If it only affects developers who generated DTs based on
> > >  960609b22be5 for internal testing, we should say that so it's
> > >  clear that no end users will see any regressions or boot
> > >  failures.
> > 
> > Whoever have included commit 960609b22be5 in their kernel and using
> > the above mentioned machines will see the failure. But looks like no
> > one really tested v7.0-rcS on these machines as we haven't gotten
> > any reports so far.
> 
> Two points:
> 
>   - a2fbecdbbb9d ("PCI: qcom: Add support for parsing the new Root
>     Port binding") is intended for hardware with multiple Root Ports
>     with independent PHY/reset controls.
> 

Not really. The commit was a prerequisite for adding multi-Root Port
controllers, but the intention is also to move the Root Port resources to Root
Port node and not stuff everything in the Host Bridge node.

>     The driver will always fall back to PHY/reset info in the host
>     bridge, so I think the only reason to do 960609b22be5 and this fix
>     is if hamoa.dtsi will also be used for hardware with multiple Root
>     Ports.  If there's no plan for multiple RPs with hamoa.dtsi,
>     reverting 960609b22be5 is another, less risky, option.
> 

That will leave things in a messy state. Our intention is to move Root Port
resources to Root Port nodes for all SoCs irrespective of whether they support
multi-RPs or not.

>   - 960609b22be5 only touches .dtsi and .dts files; it doesn't change
>     the kernel itself.
> 
>     So I assume this issue only affects somebody who used v7.0-rc1 to
>     rebuild the DTB for one of those machines and then installed that
>     new DTB on their system.  That sounds like developers to me, not
>     end users.
> 

Unfortunately, DTB is still not treated as a firmware like ACPI. And the fact
that we build the DTBs with the kernel, causes the DTBs to be updated whenever
an end user or a developer builds the kernel .deb package using 'make deb-pkg'
and installs then package using 'dpkg -i'.

And most of the users of these affected machines are pretty much both end users
and developers who know how to build the kernel themselves, so they won't be
updating the kernel through their distro update.

>     The commit log already mentions the affected machines.  I'm
>     suggesting that it should also say something about the fact that
>     only DTBs built with 960609b22be5 are affected, i.e., DTBs built
>     with 960609b22be5 but without this fix are incompatible with the
>     kernel driver.

Sure.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v1 1/1] arm64: dts: qcom: hamoa: Move PCIe PERST and Wake GPIOs to port nodes

[Manivannan Sadhasivam]

On Thu, Mar 19, 2026 at 02:50:37PM +0100, Tobias Heider wrote:
> Resending because the previous mail ended up being HTML (sorry)
> 
> On Thu, Mar 19, 2026 at 6:39 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> >
> > On Wed, Mar 18, 2026 at 09:42:56PM -0500, Bjorn Andersson wrote:
> > > On Mon, Mar 16, 2026 at 08:50:12AM +0530, Manivannan Sadhasivam wrote:
> > > > On Sun, Mar 15, 2026 at 09:53:33PM -0500, Bjorn Andersson wrote:
> > > > > On Sat, Mar 14, 2026 at 07:50:50PM +0530, Manivannan Sadhasivam wrote:
> > > > > > On Fri, Mar 13, 2026 at 11:45:42AM -0500, Bjorn Helgaas wrote:
> > > > > > > On Fri, Mar 13, 2026 at 05:46:18PM +0800, Ziyue Zhang wrote:
> > > > > > > > Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
> > > > > > > > GPIOs to PCIe port nodes and add port Nodes for all PCIe ports") did not
> > > > > > > > convert all Hamoa‑based platforms to the new method of defining PERST and
> > > > > > > > Wake GPIOs in the PCIe root port nodes.
> > > > > > > >
> > > > > > > > Without the change PCIe probe will fail. The probe failure happens because
> > > > > > > > the PHY stays in the controller node while the PERST/Wake GPIOs were moved
> > > > > > > > to the port nodes.
> > > > > > > >
> > > > > > > > This fixes probe failures seen on the following platforms:
> > > > > > > >  - x1-hp-omnibook-x14
> > > > > > > >  - x1-microsoft-denali
> > > > > > > >  - x1e80100-lenovo-yoga-slim7x
> > > > > > > >  - x1e80100-medion-sprchrgd-14-s1
> > > > > > > >  - x1p42100-lenovo-thinkbook-16
> > > > > > > >  - x1-asus-zenbook-a14
> > > > > > > >  - x1-crd
> > > > > > > >  - x1-dell-thena
> > > > > > > >
> > > > > > > > Fixes: 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
> > > > > > >
> > > > > > > Are you saying that DTs in the field broke because of some kernel
> > > > > > > change?  That's not supposed to happen.  Even though PHY, PERST, and
> > > > > > > Wake GPIOs should be described in Root Port nodes instead of the Root
> > > > > > > Complex node in *future* DTs, the kernel is still supposed to accept
> > > > > > > the old style with them described in the Root Complex node.
> > > > > > >
> > > > > >
> > > > > > This is not related to the driver change. The driver correctly parses all Root
> > > > > > Port properties either in the Root Complex node (old binding) or Root Port node
> > > > > > (new binding). But commit 960609b22be5, left converting mentioned board DTS to
> > > > > > the new binding, leaving those affected platforms in a half baked state i.e.,
> > > > > > some properties in RC node and some in Root Port node. Driver cannot parse such
> > > > > > combinations, so it fails correctly so.
> > > > > >
> > > > >
> > > > > Are you saying that above listed machines has broken PCIe support in
> > > > > v7.0-rc?
> > > > >
> > > >
> > > > I haven't verified it, but I'm pretty sure PCIe is broken on these platforms.
> > > >
> > >
> > > In line with Bjorn's request, we shouldn't have to guess.
> > >
> > > > > It seems this is a (partial) revert of 960609b22be5, is this actually
> > > > > fixing that change, or is it only applicable once some other changes are
> > > > > applied?
> > > > >
> > > >
> > > > This change is fixing the issue in the respective board DTS and is a standalone
> > > > fix on top of v7.0-rc1.
> > > >
> > >
> > > So 960609b22be5 was broken when I merged it?
> > >
> >
> > Broken on the machines mentioned in the commit message, not for all Hamoa
> > platforms.
> >
> > > The commit message says that the commit was incomplete, in that it
> > > didn't fully convert from the old to the new style, so it sounds like
> > > the offending commit was incomplete - but I believe the offending commit
> > > was a workaround for the new solution not being in place and this commit
> > > mostly reverts the changes in the offending commit.
> > >
> >
> > So 960609b22be5 was supposed to move all the platforms from old PCIe binding to
> > new for greater good, but it apparently decided to do so only for a subset of
> > the platforms for some reason which  don't know. But the problem arises due to
> > 960609b22be5 changing the hamoa.dtsi to the new binding which also warrants the
> > platform DTS to also be changed to the new binding. If we only have either dtsi
> > or dts converted and not both to the new binding, the driver will get confused
> > and fail. And this is what exactly happended for below machines:
> >
> >  - x1-hp-omnibook-x14
> >  - x1-microsoft-denali
> >  - x1e80100-lenovo-yoga-slim7x
> >  - x1e80100-medion-sprchrgd-14-s1
> >  - x1p42100-lenovo-thinkbook-16
> >  - x1-asus-zenbook-a14
> >  - x1-crd
> >  - x1-dell-thena
> 
> I can confirm the breakage for (some of) the listed devices on Ubuntu.
> We are experimenting with 7.0-rcs ahead of our 26.04 release.
> 
> I'll try to collect some test feedback for the fix.
> I'd certainly appreciate this being included as an rc fix since
> currently half of
> the x1 laptop devices are broken.
> 

Thanks for the report. We will try to get this patch into v7.0-rcS.

It'd be appreciated if you can test this patch and give your tested-by tag.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v1 1/1] arm64: dts: qcom: hamoa: Move PCIe PERST and Wake GPIOs to port nodes

[Tobias Heider]

On Tue, Mar 24, 2026 at 7:07 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
>
> On Thu, Mar 19, 2026 at 02:50:37PM +0100, Tobias Heider wrote:
> > Resending because the previous mail ended up being HTML (sorry)
> >
> > On Thu, Mar 19, 2026 at 6:39 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > >
> > > On Wed, Mar 18, 2026 at 09:42:56PM -0500, Bjorn Andersson wrote:
> > > > On Mon, Mar 16, 2026 at 08:50:12AM +0530, Manivannan Sadhasivam wrote:
> > > > > On Sun, Mar 15, 2026 at 09:53:33PM -0500, Bjorn Andersson wrote:
> > > > > > On Sat, Mar 14, 2026 at 07:50:50PM +0530, Manivannan Sadhasivam wrote:
> > > > > > > On Fri, Mar 13, 2026 at 11:45:42AM -0500, Bjorn Helgaas wrote:
> > > > > > > > On Fri, Mar 13, 2026 at 05:46:18PM +0800, Ziyue Zhang wrote:
> > > > > > > > > Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
> > > > > > > > > GPIOs to PCIe port nodes and add port Nodes for all PCIe ports") did not
> > > > > > > > > convert all Hamoa‑based platforms to the new method of defining PERST and
> > > > > > > > > Wake GPIOs in the PCIe root port nodes.
> > > > > > > > >
> > > > > > > > > Without the change PCIe probe will fail. The probe failure happens because
> > > > > > > > > the PHY stays in the controller node while the PERST/Wake GPIOs were moved
> > > > > > > > > to the port nodes.
> > > > > > > > >
> > > > > > > > > This fixes probe failures seen on the following platforms:
> > > > > > > > >  - x1-hp-omnibook-x14
> > > > > > > > >  - x1-microsoft-denali
> > > > > > > > >  - x1e80100-lenovo-yoga-slim7x
> > > > > > > > >  - x1e80100-medion-sprchrgd-14-s1
> > > > > > > > >  - x1p42100-lenovo-thinkbook-16
> > > > > > > > >  - x1-asus-zenbook-a14
> > > > > > > > >  - x1-crd
> > > > > > > > >  - x1-dell-thena
> > > > > > > > >
> > > > > > > > > Fixes: 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
> > > > > > > >
> > > > > > > > Are you saying that DTs in the field broke because of some kernel
> > > > > > > > change?  That's not supposed to happen.  Even though PHY, PERST, and
> > > > > > > > Wake GPIOs should be described in Root Port nodes instead of the Root
> > > > > > > > Complex node in *future* DTs, the kernel is still supposed to accept
> > > > > > > > the old style with them described in the Root Complex node.
> > > > > > > >
> > > > > > >
> > > > > > > This is not related to the driver change. The driver correctly parses all Root
> > > > > > > Port properties either in the Root Complex node (old binding) or Root Port node
> > > > > > > (new binding). But commit 960609b22be5, left converting mentioned board DTS to
> > > > > > > the new binding, leaving those affected platforms in a half baked state i.e.,
> > > > > > > some properties in RC node and some in Root Port node. Driver cannot parse such
> > > > > > > combinations, so it fails correctly so.
> > > > > > >
> > > > > >
> > > > > > Are you saying that above listed machines has broken PCIe support in
> > > > > > v7.0-rc?
> > > > > >
> > > > >
> > > > > I haven't verified it, but I'm pretty sure PCIe is broken on these platforms.
> > > > >
> > > >
> > > > In line with Bjorn's request, we shouldn't have to guess.
> > > >
> > > > > > It seems this is a (partial) revert of 960609b22be5, is this actually
> > > > > > fixing that change, or is it only applicable once some other changes are
> > > > > > applied?
> > > > > >
> > > > >
> > > > > This change is fixing the issue in the respective board DTS and is a standalone
> > > > > fix on top of v7.0-rc1.
> > > > >
> > > >
> > > > So 960609b22be5 was broken when I merged it?
> > > >
> > >
> > > Broken on the machines mentioned in the commit message, not for all Hamoa
> > > platforms.
> > >
> > > > The commit message says that the commit was incomplete, in that it
> > > > didn't fully convert from the old to the new style, so it sounds like
> > > > the offending commit was incomplete - but I believe the offending commit
> > > > was a workaround for the new solution not being in place and this commit
> > > > mostly reverts the changes in the offending commit.
> > > >
> > >
> > > So 960609b22be5 was supposed to move all the platforms from old PCIe binding to
> > > new for greater good, but it apparently decided to do so only for a subset of
> > > the platforms for some reason which  don't know. But the problem arises due to
> > > 960609b22be5 changing the hamoa.dtsi to the new binding which also warrants the
> > > platform DTS to also be changed to the new binding. If we only have either dtsi
> > > or dts converted and not both to the new binding, the driver will get confused
> > > and fail. And this is what exactly happended for below machines:
> > >
> > >  - x1-hp-omnibook-x14
> > >  - x1-microsoft-denali
> > >  - x1e80100-lenovo-yoga-slim7x
> > >  - x1e80100-medion-sprchrgd-14-s1
> > >  - x1p42100-lenovo-thinkbook-16
> > >  - x1-asus-zenbook-a14
> > >  - x1-crd
> > >  - x1-dell-thena
> >
> > I can confirm the breakage for (some of) the listed devices on Ubuntu.
> > We are experimenting with 7.0-rcs ahead of our 26.04 release.
> >
> > I'll try to collect some test feedback for the fix.
> > I'd certainly appreciate this being included as an rc fix since
> > currently half of
> > the x1 laptop devices are broken.
> >
>
> Thanks for the report. We will try to get this patch into v7.0-rcS.
>
> It'd be appreciated if you can test this patch and give your tested-by tag.
>
> - Mani

Thank you!

Tested it myself and I have rolled this out to my ubuntu-concept testing repo.
I have tested the CRD and got user feedback that it works on at least an
Omnibook (where we first saw the regression without the patch) and Lenovo Yoga.
Potentially more but not everyone provides feedback when things don't break.

Tested-by: Tobias Heider <tobias.heider@canonical.com>

>
> --
> மணிவண்ணன் சதாசிவம்

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v1 1/1] arm64: dts: qcom: hamoa: Move PCIe PERST and Wake GPIOs to port nodes

[Bjorn Helgaas]

[->to: Bjorn A.]

On Tue, Mar 24, 2026 at 08:14:39PM +0100, Tobias Heider wrote:
> On Tue, Mar 24, 2026 at 7:07 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > On Thu, Mar 19, 2026 at 02:50:37PM +0100, Tobias Heider wrote:
> > > On Thu, Mar 19, 2026 at 6:39 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > > On Wed, Mar 18, 2026 at 09:42:56PM -0500, Bjorn Andersson wrote:
> > > > > On Mon, Mar 16, 2026 at 08:50:12AM +0530, Manivannan Sadhasivam wrote:
> > > > > > On Sun, Mar 15, 2026 at 09:53:33PM -0500, Bjorn Andersson wrote:
> > > > > > > On Sat, Mar 14, 2026 at 07:50:50PM +0530, Manivannan Sadhasivam wrote:
> > > > > > > > On Fri, Mar 13, 2026 at 11:45:42AM -0500, Bjorn Helgaas wrote:
> > > > > > > > > On Fri, Mar 13, 2026 at 05:46:18PM +0800, Ziyue Zhang wrote:
> > > > > > > > > > Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
> > > > > > > > > > GPIOs to PCIe port nodes and add port Nodes for all PCIe ports") did not
> > > > > > > > > > convert all Hamoa‑based platforms to the new method of defining PERST and
> > > > > > > > > > Wake GPIOs in the PCIe root port nodes.
> > > > > > > > > >
> > > > > > > > > > Without the change PCIe probe will fail. The probe failure happens because
> > > > > > > > > > the PHY stays in the controller node while the PERST/Wake GPIOs were moved
> > > > > > > > > > to the port nodes.
> > > > > > > > > >
> > > > > > > > > > This fixes probe failures seen on the following platforms:
> > > > > > > > > >  - x1-hp-omnibook-x14
> > > > > > > > > >  - x1-microsoft-denali
> > > > > > > > > >  - x1e80100-lenovo-yoga-slim7x
> > > > > > > > > >  - x1e80100-medion-sprchrgd-14-s1
> > > > > > > > > >  - x1p42100-lenovo-thinkbook-16
> > > > > > > > > >  - x1-asus-zenbook-a14
> > > > > > > > > >  - x1-crd
> > > > > > > > > >  - x1-dell-thena
> > > > > > > > > >
> > > > > > > > > > Fixes: 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
> > > > > > > > >
> > > > > > > > > Are you saying that DTs in the field broke because of some kernel
> > > > > > > > > change?  That's not supposed to happen.  Even though PHY, PERST, and
> > > > > > > > > Wake GPIOs should be described in Root Port nodes instead of the Root
> > > > > > > > > Complex node in *future* DTs, the kernel is still supposed to accept
> > > > > > > > > the old style with them described in the Root Complex node.
> > > > > > > > >
> > > > > > > >
> > > > > > > > This is not related to the driver change. The driver correctly parses all Root
> > > > > > > > Port properties either in the Root Complex node (old binding) or Root Port node
> > > > > > > > (new binding). But commit 960609b22be5, left converting mentioned board DTS to
> > > > > > > > the new binding, leaving those affected platforms in a half baked state i.e.,
> > > > > > > > some properties in RC node and some in Root Port node. Driver cannot parse such
> > > > > > > > combinations, so it fails correctly so.
> > > > > > > >
> > > > > > >
> > > > > > > Are you saying that above listed machines has broken PCIe support in
> > > > > > > v7.0-rc?
> > > > > > >
> > > > > >
> > > > > > I haven't verified it, but I'm pretty sure PCIe is broken on these platforms.
> > > > > >
> > > > >
> > > > > In line with Bjorn's request, we shouldn't have to guess.
> > > > >
> > > > > > > It seems this is a (partial) revert of 960609b22be5, is this actually
> > > > > > > fixing that change, or is it only applicable once some other changes are
> > > > > > > applied?
> > > > > > >
> > > > > >
> > > > > > This change is fixing the issue in the respective board DTS and is a standalone
> > > > > > fix on top of v7.0-rc1.
> > > > > >
> > > > >
> > > > > So 960609b22be5 was broken when I merged it?
> > > > >
> > > >
> > > > Broken on the machines mentioned in the commit message, not for all Hamoa
> > > > platforms.
> > > >
> > > > > The commit message says that the commit was incomplete, in that it
> > > > > didn't fully convert from the old to the new style, so it sounds like
> > > > > the offending commit was incomplete - but I believe the offending commit
> > > > > was a workaround for the new solution not being in place and this commit
> > > > > mostly reverts the changes in the offending commit.
> > > > >
> > > >
> > > > So 960609b22be5 was supposed to move all the platforms from old PCIe binding to
> > > > new for greater good, but it apparently decided to do so only for a subset of
> > > > the platforms for some reason which  don't know. But the problem arises due to
> > > > 960609b22be5 changing the hamoa.dtsi to the new binding which also warrants the
> > > > platform DTS to also be changed to the new binding. If we only have either dtsi
> > > > or dts converted and not both to the new binding, the driver will get confused
> > > > and fail. And this is what exactly happended for below machines:
> > > >
> > > >  - x1-hp-omnibook-x14
> > > >  - x1-microsoft-denali
> > > >  - x1e80100-lenovo-yoga-slim7x
> > > >  - x1e80100-medion-sprchrgd-14-s1
> > > >  - x1p42100-lenovo-thinkbook-16
> > > >  - x1-asus-zenbook-a14
> > > >  - x1-crd
> > > >  - x1-dell-thena
> > >
> > > I can confirm the breakage for (some of) the listed devices on Ubuntu.
> > > We are experimenting with 7.0-rcs ahead of our 26.04 release.
> > >
> > > I'll try to collect some test feedback for the fix.
> > > I'd certainly appreciate this being included as an rc fix since
> > > currently half of
> > > the x1 laptop devices are broken.
> > >
> >
> > Thanks for the report. We will try to get this patch into v7.0-rcS.
> >
> > It'd be appreciated if you can test this patch and give your tested-by tag.
> >
> > - Mani
> 
> Thank you!
> 
> Tested it myself and I have rolled this out to my ubuntu-concept testing repo.
> I have tested the CRD and got user feedback that it works on at least an
> Omnibook (where we first saw the regression without the patch) and Lenovo Yoga.
> Potentially more but not everyone provides feedback when things don't break.
> 
> Tested-by: Tobias Heider <tobias.heider@canonical.com>

I don't see this patch upstream yet.  It's a fix for 960609b22be5
("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe
port nodes and add port Nodes for all PCIe ports"), which looks like
it was merged by Bjorn A., so I assume the fix will go the same route?

Just want to make sure it's not waiting on me :)

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v1 1/1] arm64: dts: qcom: hamoa: Move PCIe PERST and Wake GPIOs to port nodes

[Manivannan Sadhasivam]

On Fri, Mar 27, 2026 at 09:17:56AM -0500, Bjorn Helgaas wrote:
> [->to: Bjorn A.]
> 
> On Tue, Mar 24, 2026 at 08:14:39PM +0100, Tobias Heider wrote:
> > On Tue, Mar 24, 2026 at 7:07 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > On Thu, Mar 19, 2026 at 02:50:37PM +0100, Tobias Heider wrote:
> > > > On Thu, Mar 19, 2026 at 6:39 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > > > On Wed, Mar 18, 2026 at 09:42:56PM -0500, Bjorn Andersson wrote:
> > > > > > On Mon, Mar 16, 2026 at 08:50:12AM +0530, Manivannan Sadhasivam wrote:
> > > > > > > On Sun, Mar 15, 2026 at 09:53:33PM -0500, Bjorn Andersson wrote:
> > > > > > > > On Sat, Mar 14, 2026 at 07:50:50PM +0530, Manivannan Sadhasivam wrote:
> > > > > > > > > On Fri, Mar 13, 2026 at 11:45:42AM -0500, Bjorn Helgaas wrote:
> > > > > > > > > > On Fri, Mar 13, 2026 at 05:46:18PM +0800, Ziyue Zhang wrote:
> > > > > > > > > > > Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
> > > > > > > > > > > GPIOs to PCIe port nodes and add port Nodes for all PCIe ports") did not
> > > > > > > > > > > convert all Hamoa‑based platforms to the new method of defining PERST and
> > > > > > > > > > > Wake GPIOs in the PCIe root port nodes.
> > > > > > > > > > >
> > > > > > > > > > > Without the change PCIe probe will fail. The probe failure happens because
> > > > > > > > > > > the PHY stays in the controller node while the PERST/Wake GPIOs were moved
> > > > > > > > > > > to the port nodes.
> > > > > > > > > > >
> > > > > > > > > > > This fixes probe failures seen on the following platforms:
> > > > > > > > > > >  - x1-hp-omnibook-x14
> > > > > > > > > > >  - x1-microsoft-denali
> > > > > > > > > > >  - x1e80100-lenovo-yoga-slim7x
> > > > > > > > > > >  - x1e80100-medion-sprchrgd-14-s1
> > > > > > > > > > >  - x1p42100-lenovo-thinkbook-16
> > > > > > > > > > >  - x1-asus-zenbook-a14
> > > > > > > > > > >  - x1-crd
> > > > > > > > > > >  - x1-dell-thena
> > > > > > > > > > >
> > > > > > > > > > > Fixes: 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
> > > > > > > > > >
> > > > > > > > > > Are you saying that DTs in the field broke because of some kernel
> > > > > > > > > > change?  That's not supposed to happen.  Even though PHY, PERST, and
> > > > > > > > > > Wake GPIOs should be described in Root Port nodes instead of the Root
> > > > > > > > > > Complex node in *future* DTs, the kernel is still supposed to accept
> > > > > > > > > > the old style with them described in the Root Complex node.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > This is not related to the driver change. The driver correctly parses all Root
> > > > > > > > > Port properties either in the Root Complex node (old binding) or Root Port node
> > > > > > > > > (new binding). But commit 960609b22be5, left converting mentioned board DTS to
> > > > > > > > > the new binding, leaving those affected platforms in a half baked state i.e.,
> > > > > > > > > some properties in RC node and some in Root Port node. Driver cannot parse such
> > > > > > > > > combinations, so it fails correctly so.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Are you saying that above listed machines has broken PCIe support in
> > > > > > > > v7.0-rc?
> > > > > > > >
> > > > > > >
> > > > > > > I haven't verified it, but I'm pretty sure PCIe is broken on these platforms.
> > > > > > >
> > > > > >
> > > > > > In line with Bjorn's request, we shouldn't have to guess.
> > > > > >
> > > > > > > > It seems this is a (partial) revert of 960609b22be5, is this actually
> > > > > > > > fixing that change, or is it only applicable once some other changes are
> > > > > > > > applied?
> > > > > > > >
> > > > > > >
> > > > > > > This change is fixing the issue in the respective board DTS and is a standalone
> > > > > > > fix on top of v7.0-rc1.
> > > > > > >
> > > > > >
> > > > > > So 960609b22be5 was broken when I merged it?
> > > > > >
> > > > >
> > > > > Broken on the machines mentioned in the commit message, not for all Hamoa
> > > > > platforms.
> > > > >
> > > > > > The commit message says that the commit was incomplete, in that it
> > > > > > didn't fully convert from the old to the new style, so it sounds like
> > > > > > the offending commit was incomplete - but I believe the offending commit
> > > > > > was a workaround for the new solution not being in place and this commit
> > > > > > mostly reverts the changes in the offending commit.
> > > > > >
> > > > >
> > > > > So 960609b22be5 was supposed to move all the platforms from old PCIe binding to
> > > > > new for greater good, but it apparently decided to do so only for a subset of
> > > > > the platforms for some reason which  don't know. But the problem arises due to
> > > > > 960609b22be5 changing the hamoa.dtsi to the new binding which also warrants the
> > > > > platform DTS to also be changed to the new binding. If we only have either dtsi
> > > > > or dts converted and not both to the new binding, the driver will get confused
> > > > > and fail. And this is what exactly happended for below machines:
> > > > >
> > > > >  - x1-hp-omnibook-x14
> > > > >  - x1-microsoft-denali
> > > > >  - x1e80100-lenovo-yoga-slim7x
> > > > >  - x1e80100-medion-sprchrgd-14-s1
> > > > >  - x1p42100-lenovo-thinkbook-16
> > > > >  - x1-asus-zenbook-a14
> > > > >  - x1-crd
> > > > >  - x1-dell-thena
> > > >
> > > > I can confirm the breakage for (some of) the listed devices on Ubuntu.
> > > > We are experimenting with 7.0-rcs ahead of our 26.04 release.
> > > >
> > > > I'll try to collect some test feedback for the fix.
> > > > I'd certainly appreciate this being included as an rc fix since
> > > > currently half of
> > > > the x1 laptop devices are broken.
> > > >
> > >
> > > Thanks for the report. We will try to get this patch into v7.0-rcS.
> > >
> > > It'd be appreciated if you can test this patch and give your tested-by tag.
> > >
> > > - Mani
> > 
> > Thank you!
> > 
> > Tested it myself and I have rolled this out to my ubuntu-concept testing repo.
> > I have tested the CRD and got user feedback that it works on at least an
> > Omnibook (where we first saw the regression without the patch) and Lenovo Yoga.
> > Potentially more but not everyone provides feedback when things don't break.
> > 
> > Tested-by: Tobias Heider <tobias.heider@canonical.com>
> 
> I don't see this patch upstream yet.  It's a fix for 960609b22be5
> ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe
> port nodes and add port Nodes for all PCIe ports"), which looks like
> it was merged by Bjorn A., so I assume the fix will go the same route?
> 
> Just want to make sure it's not waiting on me :)

No. Ziyue will post it asap.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy