Devicetree
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Wei Deng" <wei.deng@oss.qualcomm.com>
Cc: conor+dt@kernel.org, devicetree@vger.kernel.org, robh@kernel.org
Subject: Re: [PATCH v4 3/4] arm64: dts: qcom: hamoa-iot-evk: Describe the PCIe M.2 Key E connector
Date: Tue, 04 Aug 2026 12:44:37 +0000	[thread overview]
Message-ID: <20260804124438.E23191F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260804-hamoa-m2-dts-v2-v4-3-1b5ceac74538@oss.qualcomm.com>

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 <wei.deng@oss.qualcomm.com>

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/20260804-hamoa-m2-dts-v2-v4-0-1b5ceac74538@oss.qualcomm.com?part=3

  reply	other threads:[~2026-08-04 12:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-04 12:32 [PATCH v4 0/4] arm64: dts: qcom: hamoa-iot-evk, purwa-iot-evk: Enable M.2 Key E connector Wei Deng
2026-08-04 12:32 ` [PATCH v4 1/4] arm64: dts: qcom: hamoa: Add graph port/endpoint anchors to pcie4_port0 and uart14 Wei Deng
2026-08-04 12:32 ` [PATCH v4 2/4] arm64: dts: qcom: hamoa: Add compatible to the PCIe Root Port Wei Deng
2026-08-04 12:32 ` [PATCH v4 3/4] arm64: dts: qcom: hamoa-iot-evk: Describe the PCIe M.2 Key E connector Wei Deng
2026-08-04 12:44   ` sashiko-bot [this message]
2026-08-04 12:32 ` [PATCH v4 4/4] arm64: dts: qcom: purwa-iot-evk: " Wei Deng
2026-08-04 12:49   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260804124438.E23191F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=wei.deng@oss.qualcomm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox