[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

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 1/3] arm64: dts: qcom: hamoa: Number usb_2 HS port and add M.2 endpoint stubs

[Wei Deng]

Hi Konrad,

On Wed, Jul 29, 2026 at 12:46:49PM +0200, Konrad Dybcio wrote:
> 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

Thanks for the review. I tried (1) locally — repointing the existing
usb_2_dwc3_hs endpoint at the M.2 graph and keeping the singular
"port { endpoint { ... } }" structure — and hit a functional failure
I'd like your and Chen-Yu's input on before v4.

Test on Hamoa IoT EVK with the Chen-Yu Tsai V6 pwrseq series applied [1]:

  Option A (v3 as posted: ports { port@0 { usb_2_dwc3_hs }; port@1 {
  usb_2_m2_ep }; }):
      BT USB device enumerates; pwrseq_m2 refcount matches expectation.

  Option (1) (singular port { usb_2_dwc3_hs } with remote-endpoint
  pointing to M.2's port@2):
      BT USB does not enumerate; pwrseq_m2 refcount is 1 less than the
      Option A run.

Root cause, following the V6 series:

  V6 patch 6 (usb: hub: Associate port@ fwnode with USB port device),
  for each USB roothub port, calls

      fwnode_graph_get_port_by_id(fwnode, port1, ...)

  where port1 is the USB port number (starts at 1). usb_2 is HS-only
  (maximum-speed = "high-speed", single usb2-phy), so this is called
  with port1 = 1 and looks up a DT node with reg = <1>.

  V6 patch 12 (pwrseq-pcie-m2: support matching on remote "port"
  node) uses of_graph_get_remote_port(endpoint) to match the USB port
  device's of_node against the M.2 endpoint's remote port.

Under Option (1) the singular "port { }" has no reg, so
port_by_id(1) returns NULL, port_dev->dev.of_node is left NULL, the
pcie-m2 match falls through, pwrseq_get() is never called for the USB
target, port->pwrseq stays NULL, and W_DISABLE2# is never deasserted
from the USB path. That's the missing refcount and the failed
enumeration. Under Option A, port@1's reg = <1> matches port1 = 1,
graph walks all the way to the M.2 slot and pwrseq_get() succeeds.

So on your (2) and (3): I don't disagree that "port@1 = SS" and "one
endpoint per physical HS connection" are what the current
snps,dwc3-common.yaml wants. The v3 shape is what works against the V6
fwnode lookup, not what I think is semantically clean. Choice seems to
be between:

  (a) keep "port@1 = SS" — then USB port 1 on a HS-only DWC3 has
      nowhere to advertise its downstream connector node to the V6
      lookup, and this M.2 wiring is not expressible; or

  (b) renumber snps,dwc3 ports to match USB port numbering (port@1 =
      HS if HS-only or SS if SS-capable, port@2 = HS if SS-capable),
      parallel to Chen-Yu's mediatek,mtk-xhci change in V6 patch 11 [2].

I want to avoid redefining the binding unilaterally, so two questions:

  Konrad: is there a DTS pattern I'm missing that would satisfy the
  current binding and still let fwnode_graph_get_port_by_id(fwnode, 1,
  ...) land on the M.2 connector for USB port 1? If not, would you be
  open to a snps,dwc3-common.yaml renumbering patch along the lines of
  Chen-Yu's mtk-xhci change?

  Chen-Yu: given the parallel with your patch 11, does snps,dwc3 need
  the same treatment on the QCom side, and would you rather see that
  patch go in ahead of your V6 or as a followup?

The 3/3 sort-order comment will be fixed in v4 regardless.

[1] https://lore.kernel.org/all/20260721065413.2306137-1-wenst@chromium.org/
[2] https://lore.kernel.org/all/20260721065413.2306137-12-wenst@chromium.org/

Thanks,

-- 
Best Regards,
Wei Deng

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

[Konrad Dybcio]

On 7/31/26 9:33 AM, Wei Deng wrote:
> Hi Konrad,
> 
> On Wed, Jul 29, 2026 at 12:46:49PM +0200, Konrad Dybcio wrote:
>> 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>
>>> ---

[...]

> I want to avoid redefining the binding unilaterally, so two questions:
> 
>   Konrad: is there a DTS pattern I'm missing that would satisfy the
>   current binding and still let fwnode_graph_get_port_by_id(fwnode, 1,
>   ...) land on the M.2 connector for USB port 1? If not, would you be
>   open to a snps,dwc3-common.yaml renumbering patch along the lines of
>   Chen-Yu's mtk-xhci change?

Thanks for the detailed story. I'll respond to that series directly.

Konrad

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

[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 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