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

[sashiko-bot@kernel.org]

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