[PATCH v4 0/4] arm64: dts: qcom: hamoa-iot-evk, purwa-iot-evk: Enable M.2 Key E connector

[PATCH v4 0/4] arm64: dts: qcom: hamoa-iot-evk, purwa-iot-evk: Enable M.2 Key E connector

[Wei Deng]

Describe the PCIe M.2 Key E connector on the Hamoa and Purwa IoT EVKs.
The two boards share the same M.2 wiring: PCIe for Wi-Fi (via
pcie4_port0) and UART for Bluetooth (via uart14). Purwa inherits
hamoa.dtsi through purwa.dtsi, so the endpoint stub labels and the
PCIe root port compatible added in this series apply to both boards.

Only the UART BT path is described here. USB BT variants of the same
M.2 slot need the USB core to acquire the M.2 pwrseq target, which is
being added by Chen-Yu Tsai's "arm64: mediatek: Add M.2 E-key slot on
Chromebooks" series:
https://lore.kernel.org/all/20260724084328.3943997-1-wenst@chromium.org/
A follow-up will wire usb_2 port@1 to the wifi-bt-connector node once
that lands.

The pcie-m2 sub-ID patch that was part of the original series has been
sent independently and is already applied:
https://lore.kernel.org/all/20260724-hamoa-m2-sub-id-v2-v3-1-af97de70bbbe@oss.qualcomm.com/

Changes in v4:
- Drop the usb_2 port numbering hunk from patch 1/4 (was "hamoa:
  Number usb_2 HS port and add M.2 endpoint stubs"). port@1 =
  usb_2_m2_ep hit the snps,dwc3-common.yaml "port@1 = SS" schema and
  was NAK'd by Konrad; the outstanding binding question is discussed
  in Konrad's replies on Chen-Yu's V6 series (patches 6 and 11):
  https://lore.kernel.org/all/c6526ba0-be08-46c6-a501-1b161939657c@oss.qualcomm.com/
  Patch 1/4 now only adds the uart14_ep and pcie4_port0_ep endpoint
  stubs (Konrad had asked for these as label references).
- Drop port@2 (USB) from the hamoa-iot-evk wifi-bt-connector node.
  The connector only advertises PCIe (port@0) and UART (port@3).
- Drop the &usb_2_dwc3_hs endpoint override.
- Add new patch 4/4 for purwa-iot-evk.dts, reusing the same connector
  layout and the labels inherited via hamoa.dtsi.
- Drop "Depends on:" — this series is now independent of Chen-Yu's
  MediaTek Chromebook series.
- Link to v3: https://lore.kernel.org/r/20260729-hamoa-m2-dts-v2-v3-0-4d7ef9274575@oss.qualcomm.com

Changes in v3:
- patch 1: 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: 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 the original series 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 as
  the new port@2 endpoint and vreg cleanup were not part of the v1
  review scope.
- Drop patch 3/3 of v1 (W_DISABLE2# else-branch); the Chen-Yu series
  handles it via USB pwrseq (Mani).
- Link to v1: https://lore.kernel.org/r/20260709-fix-hamoa-m2-w-disable2-v1-0-5e725091266a@oss.qualcomm.com

Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
---
Wei Deng (4):
      arm64: dts: qcom: hamoa: Add graph port/endpoint anchors to pcie4_port0 and uart14
      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
      arm64: dts: qcom: purwa-iot-evk: Describe the PCIe M.2 Key E connector

 arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts | 130 +++++++----------------------
 arch/arm64/boot/dts/qcom/hamoa.dtsi        |  11 +++
 arch/arm64/boot/dts/qcom/purwa-iot-evk.dts | 129 +++++++---------------------
 3 files changed, 74 insertions(+), 196 deletions(-)
---
base-commit: 290aaf24a551d5a0dce037e3fab30820f9113a10
change-id: 20260723-hamoa-m2-dts-v2-2067c7421569

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

[PATCH v4 1/4] arm64: dts: qcom: hamoa: Add graph port/endpoint anchors to pcie4_port0 and uart14

[Wei Deng]

Add empty graph port/endpoint nodes to pcie4_port0 and uart14 in hamoa.dtsi
so that board files can reference the endpoint labels (pcie4_port0_ep,
uart14_ep) to describe connections to M.2 Key E connectors via
remote-endpoint overrides.

Suggested-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 | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
index 09527dcf9576..f13e310995aa 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 {
+					};
+				};
 			};
 		};
 

-- 
2.34.1

[PATCH v4 2/4] 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 f13e310995aa..9e81fbcf42e9 100644
--- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
+++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
@@ -3781,6 +3781,7 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
 			status = "disabled";
 
 			pcie4_port0: pcie@0 {
+				compatible = "pciclass,0604";
 				device_type = "pci";
 				reg = <0x0 0x0 0x0 0x0 0x0>;
 				bus-range = <0x01 0xff>;

-- 
2.34.1

[PATCH v4 3/4] 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 UART.

Describe the connector node with:
- port@0: PCIe for Wi-Fi, linked to pcie4_port0
- port@3: UART for Bluetooth, linked to uart14

This allows the pwrseq-pcie-m2 driver to manage card power and
dynamically create the UART serdev for UART BT variants of the M.2
card.

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.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts | 130 +++++++----------------------
 1 file changed, 32 insertions(+), 98 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..776bded3a312 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";
 
@@ -677,64 +651,44 @@ 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>;
+	wifi-bt-connector {
+		compatible = "pcie-m2-e-connector";
+		vpcie3v3-supply = <&vreg_wcn_3p3>;
 
-		bt-enable-gpios = <&tlmm 116 GPIO_ACTIVE_HIGH>;
-		wlan-enable-gpios = <&tlmm 117 GPIO_ACTIVE_HIGH>;
+		w-disable1-gpios = <&tlmm 117 GPIO_ACTIVE_LOW>;
+		w-disable2-gpios = <&tlmm 116 GPIO_ACTIVE_LOW>;
 
-		pinctrl-0 = <&wcn_bt_en>, <&wcn_wlan_en>;
+		pinctrl-0 = <&wcn_wlan_en>, <&wcn_bt_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";
-			};
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
 
-			vreg_pmu_rfa_1p2: ldo6 {
-				regulator-name = "vreg_pmu_rfa_1p2";
-			};
+			port@0 {
+				reg = <0>;
+				#address-cells = <1>;
+				#size-cells = <0>;
 
-			vreg_pmu_rfa_1p8: ldo7 {
-				regulator-name = "vreg_pmu_rfa_1p8";
+				m2_e_pcie_ep: endpoint@0 {
+					reg = <0>;
+					remote-endpoint = <&pcie4_port0_ep>;
+				};
 			};
 
-			vreg_pmu_pcie_0p9: ldo8 {
-				regulator-name = "vreg_pmu_pcie_0p9";
-			};
+			port@3 {
+				reg = <3>;
+				#address-cells = <1>;
+				#size-cells = <0>;
 
-			vreg_pmu_pcie_1p8: ldo9 {
-				regulator-name = "vreg_pmu_pcie_1p8";
+				m2_e_uart_ep: endpoint@0 {
+					reg = <0>;
+					remote-endpoint = <&uart14_ep>;
+				};
 			};
 		};
 	};
+
 };
 
 &i2c1 {
@@ -1024,21 +978,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 +1473,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 {

-- 
2.34.1

Re: [PATCH v4 3/4] 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 1 potential issue(s) to consider:
- [Medium] Replacing the static `bluetooth` node with dynamic serdev instantiation drops the `max-speed = <3200000>` property, causing the Bluetooth UART to silently downgrade to 3.0 Mbps.
--

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

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

This commit describes the PCIe M.2 Key E connector for the Hamoa IoT EVK to
manage the Wi-Fi/Bluetooth module dynamically. It removes the static
chip-specific nodes in favor of a hardware-agnostic connector representation.

[ ... ]
> --- a/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
> +++ b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
[ ... ]
> @@ -1514,19 +1457,10 @@ wcn_usb_sw_n: wcn-usb-sw-n-state {
>  
>  &uart14 {
>  	status = "okay";
> +};
>  
> -	bluetooth {
> -		compatible = "qcom,wcn7850-bt";
> -		max-speed = <3200000>;

[Severity: Medium]
Will this removal of the max-speed property cause a performance regression for
the Bluetooth UART?

Looking at drivers/power/sequencing/pwrseq-pcie-m2.c, the dynamic serdev node
is constructed using an OF changeset:

pwrseq_pcie_m2_create_bt_node() {
    ...
    ret = of_changeset_add_prop_string(pci_dev->ocs, np, "compatible",
                                       compatible);
    ...
}

Because the pwrseq-pcie-m2 driver only adds the compatible string during
dynamic creation, it lacks a mechanism to propagate the board-specific
max-speed property. When the hci_qca driver probes, it will fail to read
max-speed from the dynamically generated node and fall back to its protocol
default of 3.0 Mbps instead of the expected 3.2 Mbps.

Could we retain the max-speed configuration for this board, perhaps by passing
it through the new M.2 connector node?

> -
> -		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>;
>  };
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260804-hamoa-m2-dts-v2-v4-0-1b5ceac74538@oss.qualcomm.com?part=3

[PATCH v4 4/4] arm64: dts: qcom: purwa-iot-evk: Describe the PCIe M.2 Key E connector

[Wei Deng]

The Purwa IoT EVK has a PCIe M.2 Mechanical Key E connector for wireless
connectivity cards exposing Wi-Fi over PCIe and Bluetooth over UART.
Purwa inherits hamoa.dtsi via purwa.dtsi and therefore reuses the PCIe
root port compatible and the uart14_ep / pcie4_port0_ep endpoint stub
labels added there.

Describe the connector node with:
- port@0: PCIe for Wi-Fi, linked to pcie4_port0
- port@3: UART for Bluetooth, linked to uart14

This allows the pwrseq-pcie-m2 driver to manage card power and
dynamically create the UART serdev for UART BT variants of the M.2
card.

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/purwa-iot-evk.dts | 129 +++++++----------------------
 1 file changed, 31 insertions(+), 98 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts b/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
index ad503beec1d3..6fc6fe7c0899 100644
--- a/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
+++ b/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
@@ -471,32 +471,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";
 
@@ -618,61 +592,40 @@ platform {
 		};
 	};
 
-	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>;
+	wifi-bt-connector {
+		compatible = "pcie-m2-e-connector";
+		vpcie3v3-supply = <&vreg_wcn_3p3>;
 
-		bt-enable-gpios = <&tlmm 116 GPIO_ACTIVE_HIGH>;
-		wlan-enable-gpios = <&tlmm 117 GPIO_ACTIVE_HIGH>;
+		w-disable1-gpios = <&tlmm 117 GPIO_ACTIVE_LOW>;
+		w-disable2-gpios = <&tlmm 116 GPIO_ACTIVE_LOW>;
 
-		pinctrl-0 = <&wcn_bt_en>, <&wcn_wlan_en>;
+		pinctrl-0 = <&wcn_wlan_en>, <&wcn_bt_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";
-			};
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
 
-			vreg_pmu_rfa_1p2: ldo6 {
-				regulator-name = "vreg_pmu_rfa_1p2";
-			};
+			port@0 {
+				reg = <0>;
+				#address-cells = <1>;
+				#size-cells = <0>;
 
-			vreg_pmu_rfa_1p8: ldo7 {
-				regulator-name = "vreg_pmu_rfa_1p8";
+				m2_e_pcie_ep: endpoint@0 {
+					reg = <0>;
+					remote-endpoint = <&pcie4_port0_ep>;
+				};
 			};
 
-			vreg_pmu_pcie_0p9: ldo8 {
-				regulator-name = "vreg_pmu_pcie_0p9";
-			};
+			port@3 {
+				reg = <3>;
+				#address-cells = <1>;
+				#size-cells = <0>;
 
-			vreg_pmu_pcie_1p8: ldo9 {
-				regulator-name = "vreg_pmu_pcie_1p8";
+				m2_e_uart_ep: endpoint@0 {
+					reg = <0>;
+					remote-endpoint = <&uart14_ep>;
+				};
 			};
 		};
 	};
@@ -1012,21 +965,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 {
@@ -1499,19 +1441,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 {

-- 
2.34.1

Re: [PATCH v4 4/4] arm64: dts: qcom: purwa-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] Migrating to the generic `pcie-m2-e-connector` will break Bluetooth hardware initialization because the `hci_qca` driver cannot match or acquire the power sequencer. The `hci_qca` driver requests the target name "bluetooth" (`devm_pwrseq_get(&serdev->dev, "bluetooth")`), but `pwrseq-pcie-m2` exposes its target as "uart". Furthermore, `pwrseq_pcie_m2_match()` checks whether the serdev consumer's OF node (`bluetooth`) exactly matches the parent of the M.2 remote endpoint (`uart14`), which evaluates to false. These mismatches cause `devm_pwrseq_get` to return `-ENOENT`. The `hci_qca` driver then falls back to its legacy DT-regulator fetching code path, which fails entirely because the explicit regulators (`vreg_wcn_0p95`, `vreg_wcn_1p9`) were removed in this patch. Consequently, the WCN7850 is held in reset.
- [Medium] The migration to the dynamic `pwrseq-pcie-m2` Bluetooth SerDev creation omits the UART `max-speed` property. Prior to this patch, the Bluetooth node under `uart14` explicitly defined `max-speed = <3200000>;`. The new `pwrseq-pcie-m2` driver's dynamic node instantiation logic only injects the `compatible` string into the changeset and does not carry over the `max-speed` property. As a result, the `hci_qca` driver falls back to its default operational speed of 3,000,000 baud instead of 3,200,000 baud.
--

--- Patch [4]: [PATCH v4 4/4] arm64: dts: qcom: purwa-iot-evk: Describe the PCIe M.2 Key E connector ---
commit 5f376efc44b229061a79b4f8f53cbc23e717ff9f
Author: Wei Deng <wei.deng@oss.qualcomm.com>

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

The Purwa IoT EVK has a PCIe M.2 Mechanical Key E connector for wireless
connectivity cards. This patch describes the connector node to allow the
pwrseq-pcie-m2 driver to manage card power and dynamically create the UART
serdev. It also removes the chip-specific wcn7850-pmu node and the static
bluetooth serdev under uart14.

> diff --git a/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts b/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
> index ad503beec1d3d..6fc6fe7c08995 100644
> --- a/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
> +++ b/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts

[ ... ]

> @@ -618,61 +592,40 @@ platform {
>  		};
>  	};
>  
> -	wcn7850-pmu {
> -		compatible = "qcom,wcn7850-pmu";

[ ... ]

> -			vreg_pmu_pcie_1p8: ldo9 {
> -				regulator-name = "vreg_pmu_pcie_1p8";
> -			};
>  		};
>  	};
> +
> +	wifi-bt-connector {
> +		compatible = "pcie-m2-e-connector";

[Severity: High]
Will this change break Bluetooth hardware initialization?

The hci_qca driver requests the target name "bluetooth" via devm_pwrseq_get(),
but pwrseq-pcie-m2 exposes its target as "uart".

Additionally, pwrseq_pcie_m2_match() checks whether the serdev consumer's
device tree node exactly matches the parent of the M.2 remote endpoint, which
evaluates to false here.

This mismatch causes devm_pwrseq_get() to return -ENOENT. The hci_qca driver
then falls back to its legacy device tree regulator fetching code path, which
fails entirely because the explicit regulators are removed in this patch.

Could this cause the WCN7850 to be held in reset?

> +		vpcie3v3-supply = <&vreg_wcn_3p3>;
>  
> -		bt-enable-gpios = <&tlmm 116 GPIO_ACTIVE_HIGH>;
> -		wlan-enable-gpios = <&tlmm 117 GPIO_ACTIVE_HIGH>;

[ ... ]

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

[Severity: Medium]
Does migrating to the dynamic serdev creation omit the UART max-speed
property?

The removed bluetooth node explicitly defined max-speed = <3200000>. The new
pwrseq-pcie-m2 driver's dynamic node instantiation logic only injects the
compatible string and does not carry over the max-speed property.

Because device_property_read_u32() will fail to find the property on the
dynamically created node, the hci_qca driver falls back to its default
operational speed of 3,000,000 baud instead of 3,200,000 baud.

Is there a way to preserve this performance configuration?

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

[ ... ]

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