Re: [PATCH v7 8/8] arm64: dts: qcom: monaco-arduino-monza: Add QCA2066 M.2 WiFi/BT support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] dts: qcom: missing clocks property in wireless-lga-connector
- [Low] dts: qcom: invalid bus-range property for downstream PCI bridge
--

commit 29a5722958bd298370461ff6846d50f2a2e13fa0
Author: Loic Poulain <loic.poulain@oss.qualcomm.com>

arm64: dts: qcom: monaco-arduino-monza: Add QCA2066 M.2 WiFi/BT support

This commit adds support for the QCA2066 WiFi/Bluetooth module on the
Arduino VENTUNO Q board. It introduces a wireless-lga-connector node and a
downstream pcie port to enable the M.2 slot power sequencer.

> diff --git a/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts b/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts
> index 940a03732eefc..f24a87bd7cbf6 100644
> --- a/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts
> +++ b/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts
> @@ -178,6 +178,40 @@ vreg_nvme: regulator-3p3-m2 {
>  		enable-active-high;
>  		startup-delay-us = <20000>;
>  	};
> +
> +	wireless-lga-connector {
> +		compatible = "qcom,pcie-m2-1418-lga-connector",
> +			     "pcie-m2-e-connector";
> +		vpcie3v3-supply = <&vdc_3v3>;
> +		vpcie1v8-supply = <&vdc_1v8>;
> +		w-disable1-gpios = <&tlmm 56 GPIO_ACTIVE_LOW>;
> +		w-disable2-gpios = <&tlmm 55 GPIO_ACTIVE_LOW>;

[Severity: Low]
Is the clocks property missing here in the wireless-lga-connector node for
the M.2 SUSCLK routing?

The clocks property is defined in the pcie-m2-e-connector binding and was
previously included in the legacy bluetooth node, but appears to have been
dropped during the transition to the new node. Because sleep_clk is a fixed
clock that is physically always running on this platform, the omission causes
no functional regression, but the Device Tree hardware description seems
incomplete without the SUSCLK routing.

[ ... ]
> @@ -541,6 +575,22 @@ pcie@0,0 {
>  		ranges;
>  		reg = <0x010000 0x00 0x00 0x00 0x00>;
>  
> +		pcie@1,0 {
> +			#address-cells = <3>;
> +			#size-cells = <2>;
> +			device_type = "pci";
> +			compatible = "pciclass,0604";
> +			bus-range = <0x00 0xff>;

[Severity: Low]
Does this bus-range property in the pcie@1,0 node define an invalid
secondary bus?

The bus-range property claims the downstream bridge's secondary bus is 0,
which violates PCI numbering rules since its primary bus is 2 (encoded in
the reg property as 0x020800).

The Linux PCI core dynamically reassigns invalid topologies for downstream
bridges, preventing functional breakage. However, specifying a topologically
invalid bus range in the DT seems to be an error.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261005-monza-wireless-v7-0-5a6de7662dcb@oss.qualcomm.com?part=8