Re: [PATCH v1 2/3] arm64: dts: freescale: Add support for Variscite VAR-SOM-MX8 QuadMax

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Wi-Fi and Bluetooth on the SOM will fail to probe because their enable GPIOs are never toggled and the Wi-Fi MMC host lacks the `non-removable` property.
- [High] Incomplete PMIC cooling map omits high-power A72 cores.
- [Medium] Missing PHY interrupt configuration causes fallback to polling.
--

commit c50bb64cb8cb31c1a2367dc07bbf18802022b684
Author: Stefano Radaelli <stefano.r@variscite.com>
arm64: dts: freescale: Add support for Variscite VAR-SOM-MX8 QuadMax

This commit adds device tree support for the Variscite VAR-SOM-MX8 QuadMax
system on module. It enables basic on-module peripherals including memory,
ethernet, audio, and Wi-Fi/Bluetooth functionality.

Link: https://variscite.com/system-on-module-som/i-mx-8/i-mx-8-quadmax-quadplus/var-som-mx8/

> diff --git a/arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi b/arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi
> new file mode 100644
> index 0000000000000..2ffc32ddbf51e
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi
[ ... ]
> +	mdio {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		ethphy0: ethernet-phy@4 {
> +			compatible = "ethernet-phy-ieee802.3-c22";
> +			reg = <4>;
> +			reset-gpios = <&lsio_gpio2 28 GPIO_ACTIVE_LOW>;
> +			reset-assert-us = <10000>;
> +			reset-deassert-us = <20000>;
> +			vddio-supply = <&reg_phy_vddio>;
> +		};

[Severity: Medium]
In pinctrl_fec1 below, the pin IMX8QM_ESAI0_TX4_RX1_LSIO_GPIO2_IO30 is muxed
alongside the Ethernet reset pin, suggesting it is intended as the PHY
interrupt pin. However, this ethphy0 node does not declare an interrupts
property. Will the network stack fall back to polling the PHY over the MDIO
bus, wasting CPU cycles and increasing link-state detection latency?

> +	};
> +};
[ ... ]
> +/* Bluetooth */
> +&lpuart1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_lpuart1>;
> +	uart-has-rtscts;
> +	status = "okay";
> +};

[Severity: High]
The commit message states the SOM includes Bluetooth, but this lpuart1 node
lacks a bluetooth child node to power on the Bluetooth chip. Since the
required GPIOs are muxed in pinctrl_wifi below but never actively driven, will
the Bluetooth chip remain in reset and fail to probe?

[ ... ]
> +&thermal_zones {
> +	pmic-thermal {
> +		polling-delay-passive = <250>;
> +		polling-delay = <2000>;
> +		thermal-sensors = <&tsens IMX_SC_R_PMIC_0>;
> +		trips {
> +			pmic_alert0: trip0 {
> +				temperature = <110000>;
> +				hysteresis = <2000>;
> +				type = "passive";
> +			};
> +			pmic_crit0: trip1 {
> +				temperature = <125000>;
> +				hysteresis = <2000>;
> +				type = "critical";
> +			};
> +		};
> +		cooling-maps {
> +			map0 {
> +				trip = <&pmic_alert0>;
> +				cooling-device = <&A53_0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> +						 <&A53_1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> +						 <&A53_2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> +						 <&A53_3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> +			};
> +		};
> +	};
> +};

[Severity: High]
The i.MX8QM processor has both A53 and A72 cores, but the cooling-device list
only includes the four low-power Cortex-A53 cores. If a heavy workload on the
high-power Cortex-A72 cores causes the PMIC to overheat, will the thermal
framework fail to throttle the A72 cores, risking hardware damage or sudden
thermal shutdowns?

[ ... ]
> +/* WIFI */
> +&usdhc3 {
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +	pinctrl-names = "default", "state_100mhz", "state_200mhz";
> +	pinctrl-0 = <&pinctrl_usdhc3>, <&pinctrl_wifi>;
> +	pinctrl-1 = <&pinctrl_usdhc3_100mhz>, <&pinctrl_wifi>;
> +	pinctrl-2 = <&pinctrl_usdhc3_200mhz>, <&pinctrl_wifi>;
> +	bus-width = <4>;
> +	status = "okay";

[Severity: High]
This usdhc3 node lacks the non-removable property and an mmc-pwrseq to toggle
the reset GPIO. Because the Wi-Fi chip is soldered and lacks a card-detect
pin, will the MMC subsystem treat it as a removable card, fail to detect it,
and not probe the interface?

> +
> +	brcmf: wifi@1 {
> +		compatible = "brcm,bcm4329-fmac";
> +		reg = <1>;
> +	};
> +};
[ ... ]
> +	pinctrl_fec1: fec1grp {
> +		fsl,pins = <
[ ... ]
> +			IMX8QM_ESAI0_TX2_RX3_LSIO_GPIO2_IO28			0x06000028
> +			IMX8QM_ESAI0_TX4_RX1_LSIO_GPIO2_IO30			0x06000048
> +		>;
> +	};
[ ... ]
> +	pinctrl_wifi: wifigrp {
> +		fsl,pins = <
> +			IMX8QM_SCU_GPIO0_07_SCU_DSC_RTC_CLOCK_OUTPUT_32K	0xc600004c
> +			IMX8QM_SCU_GPIO0_03_LSIO_GPIO0_IO31			0x06000021
> +			IMX8QM_SCU_GPIO0_02_LSIO_GPIO0_IO30			0x00000021
> +			IMX8QM_QSPI1A_DATA0_LSIO_GPIO4_IO26			0x00000021
> +		>;
> +	};
> +};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782812572.git.stefano.r@variscite.com?part=2