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

[sashiko-bot@kernel.org]

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