[PATCH v3 0/3] arm64: dts: qcom: hamoa-iot-evk: Enable M.2 Key E connector

[PATCH v3 0/3] arm64: dts: qcom: hamoa-iot-evk: Enable M.2 Key E connector

[Wei Deng]

Describe the PCIe M.2 Key E connector on the Hamoa IoT EVK. This is
the DTS half of [1]. The pcie-m2 sub-ID patch is sent independently
as [PATCH v2]; the W_DISABLE2# else-branch patch is dropped in favor
of Chen-Yu Tsai's series [2].

Depends on: [2]

Changes in v3:
- patch 1/3: add uart14_ep, usb_2_m2_ep and pcie4_port0_ep stub endpoints
  in hamoa.dtsi, so board DTS can reference them by label directly; remove
  superfluous comment (Konrad).
- patch 3/3: use &uart14_ep, &usb_2_m2_ep and &pcie4_port0_ep label
  references instead of re-defining port hierarchy in board DTS (Konrad).
- Link to v2: https://lore.kernel.org/r/20260723-hamoa-m2-dts-v2-v2-0-82254ac101fb@oss.qualcomm.com

Changes in v2:
- Split PATCH 1/3 of [1] into two commits (Dmitry).
- Add usb_2 HS port@0 (new patch 1/3) to pair with M.2 USB port@1.
- In patch 3/3: rename pcie4port0_ep -> pcie4_port0_ep (Konrad); add
  port@2 for the USB BT variant; remove unused vreg_wcn_0p95 /
  vreg_wcn_1p9 (sashiko). Konrad's v1 Reviewed-by is not carried:
  the new port@2 endpoint and vreg cleanup were not part of the v1
  review scope.
- Drop PATCH 3/3 of [1]; use [2] instead (Mani).

Link: [1] https://lore.kernel.org/all/20260709-fix-hamoa-m2-w-disable2-v1-0-5e725091266a@oss.qualcomm.com/
Link: [2] https://lore.kernel.org/all/20260721065413.2306137-1-wenst@chromium.org/

Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
---
Wei Deng (3):
      arm64: dts: qcom: hamoa: Number usb_2 HS port and add M.2 endpoint stubs
      arm64: dts: qcom: hamoa: Add compatible to the PCIe Root Port
      arm64: dts: qcom: hamoa-iot-evk: Describe the PCIe M.2 Key E connector

 arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts | 170 ++++++++++-------------------
 arch/arm64/boot/dts/qcom/hamoa.dtsi        |  29 ++++-
 2 files changed, 87 insertions(+), 112 deletions(-)
---
base-commit: 290aaf24a551d5a0dce037e3fab30820f9113a10
change-id: 20260723-hamoa-m2-dts-v2-2067c7421569

Best regards,
-- 
Wei Deng <wei.deng@oss.qualcomm.com>

[PATCH v3 1/3] arm64: dts: qcom: hamoa: Number usb_2 HS port and add M.2 endpoint stubs

[Wei Deng]

Number the existing High-Speed data bus port of the usb_2 DWC3
controller as port@0, consistent with the snps,dwc3 binding convention.

Also add an empty port@1 endpoint stub (usb_2_m2_ep) for the USB 2.0
interface to M.2 peripherals, and an empty UART endpoint stub
(uart14_ep) in the uart14 serial controller, so that board DTS files
can reference these labels directly without re-entering the port
hierarchy.

Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/hamoa.dtsi | 28 ++++++++++++++++++++++++++--
 1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
index 09527dcf9576..724471152fab 100644
--- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
+++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
@@ -2025,6 +2025,11 @@ &clk_virt SLAVE_QUP_CORE_1 QCOM_ICC_TAG_ALWAYS>,
 				pinctrl-names = "default";
 
 				status = "disabled";
+
+				port {
+					uart14_ep: endpoint {
+					};
+				};
 			};
 
 			i2c15: i2c@a9c000 {
@@ -3785,6 +3790,11 @@ pcie4_port0: pcie@0 {
 				#address-cells = <3>;
 				#size-cells = <2>;
 				ranges;
+
+				port {
+					pcie4_port0_ep: endpoint {
+					};
+				};
 			};
 		};
 
@@ -5134,8 +5144,22 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
 
 			status = "disabled";
 
-			port {
-				usb_2_dwc3_hs: endpoint {
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				port@0 {
+					reg = <0>;
+
+					usb_2_dwc3_hs: endpoint {
+					};
+				};
+
+				port@1 {
+					reg = <1>;
+
+					usb_2_m2_ep: endpoint {
+					};
 				};
 			};
 		};

-- 
2.34.1

[PATCH v3 2/3] arm64: dts: qcom: hamoa: Add compatible to the PCIe Root Port

[Wei Deng]

Add 'compatible = "pciclass,0604"' to the pcie4_port0 node in hamoa.dtsi
to allow the PCI subsystem to associate the DT node with the PCI-to-PCI
bridge device, which is required for M.2 connector graph endpoint
association.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/hamoa.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
index 724471152fab..767d2fb1f113 100644
--- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
+++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
@@ -3782,6 +3782,7 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
 
 			pcie4_port0: pcie@0 {
 				device_type = "pci";
+				compatible = "pciclass,0604";
 				reg = <0x0 0x0 0x0 0x0 0x0>;
 				bus-range = <0x01 0xff>;
 

-- 
2.34.1

[PATCH v3 3/3] arm64: dts: qcom: hamoa-iot-evk: Describe the PCIe M.2 Key E connector

[Wei Deng]

The Hamoa IoT EVK has a PCIe M.2 Mechanical Key E connector for wireless
connectivity cards exposing Wi-Fi over PCIe and Bluetooth over either
UART or USB, depending on the card variant.

Describe the connector node with:
- port@0: PCIe for Wi-Fi, linked to pcie4_port0
- port@2: USB for Bluetooth (USB variants), linked to usb_2 port@1
- port@3: UART for Bluetooth (UART variants), linked to uart14

This allows the pwrseq-pcie-m2 driver to manage card power and
dynamically create the UART serdev for UART BT variants, while USB
BT variants are enumerated via the USB hub pwrseq path.

Remove the chip-specific wcn7850-pmu node, the static bluetooth
serdev under uart14, and the wifi@0 PCI child node, as the M.2
connector approach replaces WCN7850-specific power sequencing with
a chip-agnostic model.

Also remove the now-unused vreg_wcn_0p95 and vreg_wcn_1p9 dummy
fixed regulators whose only consumers were the wcn7850-pmu node.

Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts | 170 ++++++++++-------------------
 1 file changed, 60 insertions(+), 110 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
index 9fa86bb6438e..34e3fb9bbdcf 100644
--- a/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
+++ b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
@@ -479,32 +479,6 @@ vph_pwr: regulator-vph-pwr {
 		regulator-boot-on;
 	};
 
-	/*
-	 * TODO: These two regulators are actually part of the removable M.2
-	 * card and not the EVK mainboard. Need to describe this differently.
-	 * Functionally it works correctly, because all we need to do is to
-	 * turn on the actual 3.3V supply above.
-	 */
-	vreg_wcn_0p95: regulator-wcn-0p95 {
-		compatible = "regulator-fixed";
-
-		regulator-name = "VREG_WCN_0P95";
-		regulator-min-microvolt = <950000>;
-		regulator-max-microvolt = <950000>;
-
-		vin-supply = <&vreg_wcn_3p3>;
-	};
-
-	vreg_wcn_1p9: regulator-wcn-1p9 {
-		compatible = "regulator-fixed";
-
-		regulator-name = "VREG_WCN_1P9";
-		regulator-min-microvolt = <1900000>;
-		regulator-max-microvolt = <1900000>;
-
-		vin-supply = <&vreg_wcn_3p3>;
-	};
-
 	vreg_wcn_3p3: regulator-wcn-3p3 {
 		compatible = "regulator-fixed";
 
@@ -538,6 +512,55 @@ vreg_wwan: regulator-wwan {
 		regulator-boot-on;
 	};
 
+	wifi-bt-connector {
+		compatible = "pcie-m2-e-connector";
+		vpcie3v3-supply = <&vreg_wcn_3p3>;
+
+		w-disable1-gpios = <&tlmm 117 GPIO_ACTIVE_LOW>;
+		w-disable2-gpios = <&tlmm 116 GPIO_ACTIVE_LOW>;
+
+		pinctrl-0 = <&wcn_wlan_en>, <&wcn_bt_en>;
+		pinctrl-names = "default";
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@0 {
+				reg = <0>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				m2_e_pcie_ep: endpoint@0 {
+					reg = <0>;
+					remote-endpoint = <&pcie4_port0_ep>;
+				};
+			};
+
+			port@2 {
+				reg = <2>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				m2_e_usb_ep: endpoint@0 {
+					reg = <0>;
+					remote-endpoint = <&usb_2_m2_ep>;
+				};
+			};
+
+			port@3 {
+				reg = <3>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				m2_e_uart_ep: endpoint@0 {
+					reg = <0>;
+					remote-endpoint = <&uart14_ep>;
+				};
+			};
+		};
+	};
+
 	sound {
 		compatible = "qcom,x1e80100-sndcard";
 		model = "X1E80100-EVK";
@@ -677,66 +700,9 @@ usb_1_ss0_sbu_mux: endpoint {
 		};
 	};
 
-	wcn7850-pmu {
-		compatible = "qcom,wcn7850-pmu";
-
-		vdd-supply = <&vreg_wcn_0p95>;
-		vddio-supply = <&vreg_l15b_1p8>;
-		vddaon-supply = <&vreg_wcn_0p95>;
-		vdddig-supply = <&vreg_wcn_0p95>;
-		vddrfa1p2-supply = <&vreg_wcn_1p9>;
-		vddrfa1p8-supply = <&vreg_wcn_1p9>;
-
-		bt-enable-gpios = <&tlmm 116 GPIO_ACTIVE_HIGH>;
-		wlan-enable-gpios = <&tlmm 117 GPIO_ACTIVE_HIGH>;
-
-		pinctrl-0 = <&wcn_bt_en>, <&wcn_wlan_en>;
-		pinctrl-names = "default";
-
-		regulators {
-			vreg_pmu_rfa_cmn: ldo0 {
-				regulator-name = "vreg_pmu_rfa_cmn";
-			};
-
-			vreg_pmu_aon_0p59: ldo1 {
-				regulator-name = "vreg_pmu_aon_0p59";
-			};
-
-			vreg_pmu_wlcx_0p8: ldo2 {
-				regulator-name = "vreg_pmu_wlcx_0p8";
-			};
-
-			vreg_pmu_wlmx_0p85: ldo3 {
-				regulator-name = "vreg_pmu_wlmx_0p85";
-			};
-
-			vreg_pmu_btcmx_0p85: ldo4 {
-				regulator-name = "vreg_pmu_btcmx_0p85";
-			};
-
-			vreg_pmu_rfa_0p8: ldo5 {
-				regulator-name = "vreg_pmu_rfa_0p8";
-			};
-
-			vreg_pmu_rfa_1p2: ldo6 {
-				regulator-name = "vreg_pmu_rfa_1p2";
-			};
-
-			vreg_pmu_rfa_1p8: ldo7 {
-				regulator-name = "vreg_pmu_rfa_1p8";
-			};
-
-			vreg_pmu_pcie_0p9: ldo8 {
-				regulator-name = "vreg_pmu_pcie_0p9";
-			};
-
-			vreg_pmu_pcie_1p8: ldo9 {
-				regulator-name = "vreg_pmu_pcie_1p8";
-			};
-		};
-	};
 };
 
+
 &i2c1 {
 	clock-frequency = <400000>;
 	status = "okay";
@@ -1024,21 +990,10 @@ &pcie3_port0 {
 &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>;
-
-		vddaon-supply = <&vreg_pmu_aon_0p59>;
-		vddwlcx-supply = <&vreg_pmu_wlcx_0p8>;
-		vddwlmx-supply = <&vreg_pmu_wlmx_0p85>;
-		vddrfacmn-supply = <&vreg_pmu_rfa_cmn>;
-		vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
-		vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
-		vddrfa1p8-supply = <&vreg_pmu_rfa_1p8>;
-		vddpcie0p9-supply = <&vreg_pmu_pcie_0p9>;
-		vddpcie1p8-supply = <&vreg_pmu_pcie_1p8>;
-	};
+&pcie4_port0_ep {
+	remote-endpoint = <&m2_e_pcie_ep>;
 };
 
 &pcie5 {
@@ -1530,19 +1485,10 @@ wcn_usb_sw_n: wcn-usb-sw-n-state {
 
 &uart14 {
 	status = "okay";
+};
 
-	bluetooth {
-		compatible = "qcom,wcn7850-bt";
-		max-speed = <3200000>;
-
-		vddaon-supply = <&vreg_pmu_aon_0p59>;
-		vddwlcx-supply = <&vreg_pmu_wlcx_0p8>;
-		vddwlmx-supply = <&vreg_pmu_wlmx_0p85>;
-		vddrfacmn-supply = <&vreg_pmu_rfa_cmn>;
-		vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
-		vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
-		vddrfa1p8-supply = <&vreg_pmu_rfa_1p8>;
-	};
+&uart14_ep {
+	remote-endpoint = <&m2_e_uart_ep>;
 };
 
 &uart21 {
@@ -1612,6 +1558,10 @@ &usb_2_hsphy {
 	pinctrl-names = "default";
 };
 
+&usb_2_m2_ep {
+	remote-endpoint = <&m2_e_usb_ep>;
+};
+
 &usb_mp_hsphy0 {
 	phys = <&eusb3_repeater>;
 };

-- 
2.34.1

Re: [PATCH v3 3/3] arm64: dts: qcom: hamoa-iot-evk: Describe the PCIe M.2 Key E connector

[Konrad Dybcio]

On 7/29/26 12:27 PM, Wei Deng wrote:
> The Hamoa IoT EVK has a PCIe M.2 Mechanical Key E connector for wireless
> connectivity cards exposing Wi-Fi over PCIe and Bluetooth over either
> UART or USB, depending on the card variant.
> 
> Describe the connector node with:
> - port@0: PCIe for Wi-Fi, linked to pcie4_port0
> - port@2: USB for Bluetooth (USB variants), linked to usb_2 port@1
> - port@3: UART for Bluetooth (UART variants), linked to uart14
> 
> This allows the pwrseq-pcie-m2 driver to manage card power and
> dynamically create the UART serdev for UART BT variants, while USB
> BT variants are enumerated via the USB hub pwrseq path.
> 
> Remove the chip-specific wcn7850-pmu node, the static bluetooth
> serdev under uart14, and the wifi@0 PCI child node, as the M.2
> connector approach replaces WCN7850-specific power sequencing with
> a chip-agnostic model.
> 
> Also remove the now-unused vreg_wcn_0p95 and vreg_wcn_1p9 dummy
> fixed regulators whose only consumers were the wcn7850-pmu node.
> 
> Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
> ---

> @@ -538,6 +512,55 @@ vreg_wwan: regulator-wwan {
>  		regulator-boot-on;
>  	};
>  
> +	wifi-bt-connector {

[...]

This node is out of sorting order now

>  	sound {
>  		compatible = "qcom,x1e80100-sndcard";
>  		model = "X1E80100-EVK";
> @@ -677,66 +700,9 @@ usb_1_ss0_sbu_mux: endpoint {
>  		};
>  	};

Konrad

Re: [PATCH v3 1/3] arm64: dts: qcom: hamoa: Number usb_2 HS port and add M.2 endpoint stubs

[Konrad Dybcio]

On 7/29/26 12:27 PM, Wei Deng wrote:
> Number the existing High-Speed data bus port of the usb_2 DWC3
> controller as port@0, consistent with the snps,dwc3 binding convention.
> 
> Also add an empty port@1 endpoint stub (usb_2_m2_ep) for the USB 2.0
> interface to M.2 peripherals, and an empty UART endpoint stub
> (uart14_ep) in the uart14 serial controller, so that board DTS files
> can reference these labels directly without re-entering the port
> hierarchy.
> 
> Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
> ---

[...]

> -			port {
> -				usb_2_dwc3_hs: endpoint {
> +			ports {
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +
> +				port@0 {
> +					reg = <0>;
> +
> +					usb_2_dwc3_hs: endpoint {
> +					};
> +				};
> +
> +				port@1 {
> +					reg = <1>;
> +
> +					usb_2_m2_ep: endpoint {
> +					};

What? Why?

1. what's wrong with assigning the existing endpoint to the m2 graph?
2. this breaks bindings - port@1 is supposed to represent the superspeed
   connection
3. why would we have two endpoints for the same physical HS connection?

Konrad

Re: [PATCH v3 3/3] arm64: dts: qcom: hamoa-iot-evk: Describe the PCIe M.2 Key E connector

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Switching to the M.2 power sequencer framework breaks Bluetooth initialization because the `hci_qca` driver and the `pwrseq-pcie-m2` driver use mismatched power sequencer target names, causing probe failure.
- [High] The `wifi-bt-connector` node omits the 1.8V IO supply (`vpcie1v8-supply`), breaking strict dependency tracking for the M.2 VIO.
- [Medium] The removal of the explicit `bluetooth` serdev node drops the `max-speed = <3200000>` property without an equivalent replacement mechanism, leading to a Bluetooth throughput regression.
--

--- Patch [3]: [PATCH v3 3/3] arm64: dts: qcom: hamoa-iot-evk: Describe the PCIe M.2 Key E connector ---
commit 519be148d37d417828c1284c945a2103a6f63bb5
Author: Wei Deng <wei.deng@oss.qualcomm.com>

arm64: dts: qcom: hamoa-iot-evk: Describe the PCIe M.2 Key E connector

This patch replaces the static WCN7850-specific Wi-Fi and Bluetooth nodes
with a dynamic pcie-m2-e-connector node. It delegates card power and dynamic
node creation to the pwrseq-pcie-m2 driver. The older dummy regulators and 
chip-specific wcn7850-pmu nodes are removed.

> diff --git a/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
> index c7ba4b353ddd2..a2632554aa83a 100644
> --- a/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
> +++ b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts

[ ... ]

> @@ -538,6 +512,55 @@ vreg_wwan: regulator-wwan {
>  		regulator-boot-on;
>  	};
>  
> +	wifi-bt-connector {
> +		compatible = "pcie-m2-e-connector";
> +		vpcie3v3-supply = <&vreg_wcn_3p3>;

[Severity: High]
This node appears to omit the 1.8V IO supply (vpcie1v8-supply) that was
previously supplied to the PMU as vddio-supply.

Since the pwrseq-pcie-m2 driver uses of_regulator_bulk_get_all() to acquire
all supplies, and vreg_l15b_1p8 is not marked as regulator-always-on in this
tree, could the IO domain lose power during runtime if all other consumers
release the 1.8V regulator?

> +
> +		w-disable1-gpios = <&tlmm 117 GPIO_ACTIVE_LOW>;
> +		w-disable2-gpios = <&tlmm 116 GPIO_ACTIVE_LOW>;

[Severity: High]
Could the w-disable2-gpios reset remain permanently asserted during Bluetooth
initialization?

When hci_qca probes the dynamic Bluetooth node, it attempts to acquire the
power sequencer using devm_pwrseq_get(&serdev->dev, "bluetooth"). However, the
pwrseq-pcie-m2 driver appears to register the target as "uart". 

Will this name mismatch cause devm_pwrseq_get() to fail with -ENOENT, 
prompting hci_qca to fall back to parsing direct regulators and GPIOs that are
no longer present, ultimately failing the probe?

> +
> +		pinctrl-0 = <&wcn_wlan_en>, <&wcn_bt_en>;
> +		pinctrl-names = "default";

[ ... ]

> @@ -1514,19 +1469,10 @@ wcn_usb_sw_n: wcn-usb-sw-n-state {
>  
>  &uart14 {
>  	status = "okay";
> +};
>  
> -	bluetooth {
> -		compatible = "qcom,wcn7850-bt";
> -		max-speed = <3200000>;

[Severity: Medium]
By removing this static bluetooth node, we lose the explicit max-speed
property. 

Does the new dynamic node generation framework in the pwrseq-pcie-m2 driver
have a mechanism to inject the max-speed property into the dynamically created
UART serdev? 

If not, will the hci_qca driver fall back to a lower default baud rate and
reduce Bluetooth throughput?

> -
> -		vddaon-supply = <&vreg_pmu_aon_0p59>;
> -		vddwlcx-supply = <&vreg_pmu_wlcx_0p8>;
> -		vddwlmx-supply = <&vreg_pmu_wlmx_0p85>;
> -		vddrfacmn-supply = <&vreg_pmu_rfa_cmn>;
> -		vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
> -		vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
> -		vddrfa1p8-supply = <&vreg_pmu_rfa_1p8>;
> -	};
> +&uart14_ep {
> +	remote-endpoint = <&m2_e_uart_ep>;
>  };
>  
>  &uart21 {

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260729-hamoa-m2-dts-v2-v3-0-4d7ef9274575@oss.qualcomm.com?part=3

Re: [PATCH v3 1/3] arm64: dts: qcom: hamoa: Number usb_2 HS port and add M.2 endpoint stubs

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The M.2 USB 2.0 endpoint stub (`usb_2_m2_ep`) is incorrectly mapped to `port@1` in the `usb_2` DWC3 controller, which violates the DWC3 OF-graph schema.
- [Low] The commit message fails to mention the addition of the PCIe endpoint stub (`pcie4_port0_ep`).
--

--- Patch [1]: [PATCH v3 1/3] arm64: dts: qcom: hamoa: Number usb_2 HS port and add M.2 endpoint stubs ---
commit 83adf4d287cf5b2273e244ab2fb06d8aa0806c46
Author: Wei Deng <wei.deng@oss.qualcomm.com>

arm64: dts: qcom: hamoa: Number usb_2 HS port and add M.2 endpoint stubs
    
Number the existing High-Speed data bus port of the usb_2 DWC3
controller as port@0, consistent with the snps,dwc3 binding convention.

Also add an empty port@1 endpoint stub (usb_2_m2_ep) for the USB 2.0
interface to M.2 peripherals, and an empty UART endpoint stub
(uart14_ep) in the uart14 serial controller, so that board DTS files
can reference these labels directly without re-entering the port
hierarchy.

> diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> index 4ba751a65142b..dbe1bec0258ce 100644
> --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
> +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
[ ... ]
> @@ -3843,6 +3848,11 @@ pcie4_port0: pcie@0 {
>  				#address-cells = <3>;
>  				#size-cells = <2>;
>  				ranges;
> +
> +				port {
> +					pcie4_port0_ep: endpoint {
> +					};
> +				};
>  			};

[Severity: Low]
This isn't a bug, but the commit message details the addition of the USB and
UART M.2 endpoint stubs without mentioning the addition of this PCIe endpoint
stub in the pcie4_port0 node.

Could the commit message be updated to mention pcie4_port0_ep as well?

[ ... ]
> @@ -5189,8 +5199,22 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
>  
>  			status = "disabled";
>  
> -			port {
> -				usb_2_dwc3_hs: endpoint {
> +			ports {
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +
> +				port@0 {
> +					reg = <0>;
> +
> +					usb_2_dwc3_hs: endpoint {
> +					};
> +				};
> +
> +				port@1 {
> +					reg = <1>;
> +
> +					usb_2_m2_ep: endpoint {
> +					};
>  				};
>  			};

[Severity: Medium]
Does mapping the M.2 USB 2.0 endpoint stub (usb_2_m2_ep) to port@1 in the usb_2
controller violate the DWC3 OF-graph schema?

The snps,dwc3-common.yaml schema explicitly reserves port@0 for the High-Speed
(USB 2.0) bus and port@1 for the Super-Speed (USB 3.0) bus.

Since the usb_2 controller is a High-Speed-only controller, attaching a USB 2.0
interface to port@1 incorrectly models the hardware by attaching it to a
non-existent SuperSpeed port.

Could this cause dtbs_check validation failures or incorrect OF-graph parsing
in drivers that expect port@1 to strictly represent a SuperSpeed link?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260729-hamoa-m2-dts-v2-v3-0-4d7ef9274575@oss.qualcomm.com?part=1