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