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

[PATCH v2 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 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 as port@0
      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 | 183 ++++++++++++-----------------
 arch/arm64/boot/dts/qcom/hamoa.dtsi        |  13 +-
 2 files changed, 86 insertions(+), 110 deletions(-)
---
base-commit: 290aaf24a551d5a0dce037e3fab30820f9113a10
change-id: 20260723-hamoa-m2-dts-v2-2067c7421569

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

[PATCH v2 1/3] arm64: dts: qcom: hamoa: Number usb_2 HS port as port@0

[Wei Deng]

Assign a port number (reg = <0>) to the existing HS data bus port in
the usb_2 DWC3 controller, renaming it from the unnumbered 'port' to
'port@0'. This is consistent with the snps,dwc3 binding convention
where port@0 denotes the High-Speed data bus.

Adding a port number also reserves port@1 for USB root hub physical
port connections (e.g. an M.2 Key E USB BT slot) that can be described
in board device tree files.

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

diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
index 09527dcf9576..833810470c85 100644
--- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
+++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
@@ -5134,8 +5134,16 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
 
 			status = "disabled";
 
-			port {
-				usb_2_dwc3_hs: endpoint {
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				/* High-speed USB 2.0 data bus */
+				port@0 {
+					reg = <0>;
+
+					usb_2_dwc3_hs: endpoint {
+					};
 				};
 			};
 		};

-- 
2.34.1

Re: [PATCH v2 1/3] arm64: dts: qcom: hamoa: Number usb_2 HS port as port@0

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The commit message establishes a broken Devicetree API contract by promoting the use of `port@1` for a downstream USB root hub physical port connection (e.g., an M.2 BT slot), which violates Devicetree topologies and schemas.
--

--- Patch [1]: [PATCH v2 1/3] arm64: dts: qcom: hamoa: Number usb_2 HS port as port@0 ---
commit 26a61b5c5bcc296d009783e2231b6c4b9b5fd3ef
Author: Wei Deng <wei.deng@oss.qualcomm.com>

arm64: dts: qcom: hamoa: Number usb_2 HS port as port@0

This patch assigns a port number to the existing high-speed data bus port in
the usb_2 DWC3 controller by wrapping it in a ports node and renaming it to
port@0. The commit message states this aligns with the snps,dwc3 binding
convention. It also claims this reserves port@1 for USB root hub physical
connections like an M.2 Key E Bluetooth slot.

> Adding a port number also reserves port@1 for USB root hub physical
> port connections (e.g. an M.2 Key E USB BT slot) that can be described
> in board device tree files.

[Severity: Medium]
Does this description conflict with standard Devicetree topologies for USB
devices?

Standard USB downstream devices are typically modeled as direct children of
the USB controller using function-based names (e.g., bluetooth@1), rather
than being modeled as OF graph endpoints.

If board developers follow this guidance and place a port@1 node inside the
ports node, won't it trigger schema validation errors? 

The snps,dwc3-common.yaml schema strictly defines port@1 in the OF graph as
a Super-Speed data bus, which conflicts with this being an HS-only controller.

Could the commit message be updated to avoid suggesting OF graph routing for
logical USB bus topologies?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260723-hamoa-m2-dts-v2-v2-0-82254ac101fb@oss.qualcomm.com?part=1

Re: [PATCH v2 1/3] arm64: dts: qcom: hamoa: Number usb_2 HS port as port@0

[Konrad Dybcio]

On 7/23/26 11:56 AM, Wei Deng wrote:
> Assign a port number (reg = <0>) to the existing HS data bus port in
> the usb_2 DWC3 controller, renaming it from the unnumbered 'port' to
> 'port@0'. This is consistent with the snps,dwc3 binding convention
> where port@0 denotes the High-Speed data bus.
> 
> Adding a port number also reserves port@1 for USB root hub physical
> port connections (e.g. an M.2 Key E USB BT slot) that can be described
> in board device tree files.
> 
> Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
> ---
>  arch/arm64/boot/dts/qcom/hamoa.dtsi | 12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> index 09527dcf9576..833810470c85 100644
> --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
> +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> @@ -5134,8 +5134,16 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
>  
>  			status = "disabled";
>  
> -			port {
> -				usb_2_dwc3_hs: endpoint {
> +			ports {
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +
> +				/* High-speed USB 2.0 data bus */

This is defined by bindings, so the comment is superfluous

Konrad

[PATCH v2 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.

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 833810470c85..dc680554cd34 100644
--- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
+++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
@@ -3777,6 +3777,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

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

[Konrad Dybcio]

On 7/23/26 11:56 AM, Wei Deng wrote:
> 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.
> 
> Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
> ---

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

Konrad

[PATCH v2 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 | 183 ++++++++++++-----------------
 1 file changed, 75 insertions(+), 108 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..cc0c03b97f4f 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,58 @@ 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>;
+
+			/* PCIe for Wi-Fi */
+			port@0 {
+				reg = <0>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				m2_e_pcie_ep: endpoint@0 {
+					reg = <0>;
+					remote-endpoint = <&pcie4_port0_ep>;
+				};
+			};
+
+			/* USB for Bluetooth */
+			port@2 {
+				reg = <2>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				m2_e_usb_ep: endpoint@0 {
+					reg = <0>;
+					remote-endpoint = <&usb_2_m2_ep>;
+				};
+			};
+
+			/* UART for Bluetooth */
+			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,64 +703,6 @@ 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 {
@@ -1025,19 +993,10 @@ &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>;
+	port {
+		pcie4_port0_ep: endpoint {
+			remote-endpoint = <&m2_e_pcie_ep>;
+		};
 	};
 };
 
@@ -1531,17 +1490,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>;
+	port {
+		uart14_ep: endpoint {
+			remote-endpoint = <&m2_e_uart_ep>;
+		};
 	};
 };
 
@@ -1612,6 +1564,21 @@ &usb_2_hsphy {
 	pinctrl-names = "default";
 };
 
+&usb_2 {
+	ports {
+		port@1 {
+			reg = <1>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			usb_2_m2_ep: endpoint@0 {
+				reg = <0>;
+				remote-endpoint = <&m2_e_usb_ep>;
+			};
+		};
+	};
+};
+
 &usb_mp_hsphy0 {
 	phys = <&eusb3_repeater>;
 };

-- 
2.34.1

Re: [PATCH v2 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 2 potential issue(s) to consider:
- [High] The power sequencing integration for the dynamically created Bluetooth serdev is fundamentally broken due to device matching and target name mismatches, leaving the Bluetooth hardware disabled in reset.
- [Medium] The omission of the `max-speed` property silently degrades the Bluetooth UART operating baud rate from 3.2 Mbps to 3.0 Mbps.
--

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

This commit replaces the Hamoa IoT EVK's chip-specific wcn7850-pmu with a
generic pcie-m2-e-connector node. It removes the static bluetooth serdev
and relies on the pwrseq-pcie-m2 driver to dynamically create the device
and manage power sequencing.

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

[ ... ]

> @@ -538,6 +512,58 @@ 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>;

[Severity: High]
Will this leave the Bluetooth hardware disabled in reset?

Because the hci_qca driver currently fails to match the power sequencer
for the "uart" target, it appears it will never un-assert w-disable2-gpios.

Does the dynamic serdev creation properly handle matching the sequencer
target name for this Bluetooth variant, or will the device fail to probe?

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

[ ... ]

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

[Severity: Medium]
Does the dynamic node creation restore this max-speed property?

Without it, the Bluetooth UART falls back to 3.0 Mbps instead of 3.2 Mbps.

This transition from an integer to a fractional clock divider increases
the risk of UART framing errors and slightly degrades throughput.

> -
> -		vddaon-supply = <&vreg_pmu_aon_0p59>;
> -		vddwlcx-supply = <&vreg_pmu_wlcx_0p8>;

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260723-hamoa-m2-dts-v2-v2-0-82254ac101fb@oss.qualcomm.com?part=3

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

[Konrad Dybcio]

On 7/23/26 11:56 AM, 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.

[...]

> +	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>;
> +
> +			/* PCIe for Wi-Fi */

Similarly, this is both defined by bindings and made obvious by
the label you assign to the endpoint

[...]

> +&usb_2 {
> +	ports {
> +		port@1 {

That's why we should use labels and references instead of nested
nodes - you defined a port different to the one in patch 1.

I feel like we should probably define the uart endpoints in the SoC
DTSI as well.

Konrad