[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

[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