Re: [PATCH RESEND v7 09/10] arm64: dts: qcom: shikra: Enable WiFi/BT on SoMs

Thank you for your contribution! Sashiko AI review found 2 potential issue(=
s) to consider:
- [High] The 0.8V WiFi core voltage (VDD_CX_MX) and the 1.8V PMU IO voltage=
 (VDDIO) are incorrectly assigned to the same regulator on both SoMs, causi=
ng severe overvoltage or undervoltage.
- [Low] The device tree uses undocumented compatible strings 'qcom,wcn3988-=
bt' and 'qcom,wcn3988-pmu'.
--

--- Patch [9]: [PATCH RESEND v7 09/10] arm64: dts: qcom: shikra: Enable WiF=
i/BT on SoMs ---
commit 30ae129f7cfc5fecf1be133f1d9e0c8ef423f904
Author: Komal Bajaj <[email protected]>

arm64: dts: qcom: shikra: Enable WiFi/BT on SoMs

This patch enables WCN3988 WiFi and Bluetooth on Shikra SoM cards. It adds
the pmu, wifi, and bluetooth device tree nodes with their corresponding
regulator supplies and calibration data.

> diff --git a/arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi b/arch/arm64/bo=
ot/dts/qcom/shikra-cqm-som.dtsi
> index dc3861489f64d..2fff5fe9f6d2f 100644
> --- a/arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi
> +++ b/arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi
[ ... ]
> @@ -27,6 +31,42 @@ key-volume-up {
>  			linux,can-disable;
>  		};
>  	};
> +
> +	wcn3988-pmu {
> +		compatible =3D "qcom,wcn3988-pmu";
> +
> +		pinctrl-0 =3D <&sw_ctrl_default>;
> +		pinctrl-names =3D "default";
> +
> +		swctrl-gpios =3D <&tlmm 88 GPIO_ACTIVE_HIGH>;
> +
> +		vddio-supply =3D <&pm4125_l7>;

[Severity: High]
Will this cause a severe undervoltage for the IO domain?

The vddio-supply typically requires 1.8V. However, it is assigned here to
pm4125_l7, which is also mapped to the 0.8V vdd-0.8-cx-mx-supply in the wifi
node later in this file.

> +		vddxo-supply =3D <&pm4125_l13>;
> +		vddrf-supply =3D <&pm4125_l10>;
> +		vddch0-supply =3D <&pm4125_l22>;
[ ... ]
> +&uart8 {
> +	status =3D "okay";
> +
> +	bluetooth {
> +		compatible =3D "qcom,wcn3988-bt";

[Severity: Low]
This isn't a bug, but are the qcom,wcn3988-bt and qcom,wcn3988-pmu
compatibles missing from the dt-bindings?

They do not appear to be documented in Documentation/devicetree/bindings/,
which might trigger device tree schema validation warnings.

> +		max-speed =3D <3200000>;
> +
> +		vddio-supply =3D <&vreg_pmu_io>;
[ ... ]
> diff --git a/arch/arm64/boot/dts/qcom/shikra-iqs-som.dtsi b/arch/arm64/bo=
ot/dts/qcom/shikra-iqs-som.dtsi
> index 73945bf42112d..657a14ca96067 100644
> --- a/arch/arm64/boot/dts/qcom/shikra-iqs-som.dtsi
> +++ b/arch/arm64/boot/dts/qcom/shikra-iqs-som.dtsi
[ ... ]
> +	wcn3988-pmu {
> +		compatible =3D "qcom,wcn3988-pmu";
> +
> +		pinctrl-0 =3D <&sw_ctrl_default>;
> +		pinctrl-names =3D "default";
> +
> +		swctrl-gpios =3D <&tlmm 88 GPIO_ACTIVE_HIGH>;
> +
> +		vddio-supply =3D <&pm8150_s4>;
> +		vddxo-supply =3D <&pm8150_l12>;
> +		vddrf-supply =3D <&pm8150_l8>;
[ ... ]
> +&wifi {
> +	vdd-0.8-cx-mx-supply =3D <&pm8150_s4>;

[Severity: High]
Could this cause hardware damage by overvolting the 0.8V WiFi core logic?

This maps the 0.8V vdd-0.8-cx-mx-supply to pm8150_s4. However, in the
wcn3988-pmu node above, pm8150_s4 is mapped to the 1.8V vddio-supply.

If pm8150_s4 has a physical minimum of 1.08V (as is common for this 1.8V
buck), will the regulator framework fail to set the 0.8V request,
leaving the 0.8V core rail subjected to over 35% overvoltage?

> +	vdd-1.8-xo-supply =3D <&vreg_pmu_xo>;
> +	vdd-1.3-rfa-supply =3D <&vreg_pmu_rf>;
> +	vdd-3.3-ch0-supply =3D <&vreg_pmu_ch0>;

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260803-shikra-dt-=
[email protected]?part=3D9