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

[email protected] Tue, 04 Aug 2026 12:44:37 +0000
Newsgroups org.kernel.vger.linux-devicetree
Message-ID <[email protected]>
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 <[email protected]>

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/[email protected]?part=3