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

[Frank Li <Frank.li@oss.nxp.com>]

On Tue, Jun 30, 2026 at 10:07:11AM +0000, sashiko-bot@kernel.org wrote:
> 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?
>

Please check it.

> > +	};
> > +};
> [ ... ]
> > +/* 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?


Please check it!

Frank
>
> > +
> > +	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
>