Re: [PATCH v5 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] The `usdhc3` WiFi SDIO host is marked `non-removable` but assigns user-space WiFi initialization GPIOs to its pinctrl state, breaking initialization.
- [Medium] The statically defined `memory` node declares 1GB of RAM, but the `linux,cma` region is placed strictly outside this memory range.
- [Low] The audio regulator node is named `regulator-3p3v` but configured for 1.8V.
--

--- Patch [2]: [PATCH v5 2/3] arm64: dts: freescale: Add support for Variscite VAR-SOM-MX8 QuadMax ---
commit e6616ac5ca38d036f01cf07cc3cd9713d0d5a5cc
Author: Stefano Radaelli <stefano.r@variscite.com>

arm64: dts: freescale: Add support for Variscite VAR-SOM-MX8 QuadMax

Add device tree support for the Variscite VAR-SOM-MX8 QuadMax system
on module. The module includes an i.MX8 QuadMax processor, LPDDR4 memory,
eMMC, Ethernet, audio codec, and WiFi/Bluetooth connectivity.

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..28964de3b080a
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8qm-var-som.dtsi
> @@ -0,0 +1,531 @@
[ ... ]
> +	memory@80000000 {
> +		device_type = "memory";
> +		reg = <0x00000000 0x80000000 0 0x40000000>;
> +	};
> +
> +	reg_audio_supply: regulator-3p3v {
> +		compatible = "regulator-fixed";
> +		regulator-name = "wm8904-supply";
> +		regulator-min-microvolt = <1800000>;
> +		regulator-max-microvolt = <1800000>;

[Severity: Low]
This isn't a bug, but the node name specifies 3.3V while the configured
voltage is explicitly 1.8V. Should this node be named regulator-1p8v
instead?

> +		regulator-always-on;
> +	};
[ ... ]
> +		/* global autoconfigured region for contiguous allocations */
> +		linux,cma {
> +			compatible = "shared-dma-pool";
> +			/* VAR-SOM-MX8QM doesn't have 1GB variant */
> +			alloc-ranges = <0 0xc0000000 0 0x3c000000>;

[Severity: Medium]
Does this CMA allocation succeed if the bootloader doesn't dynamically patch
the memory size?

The memory@80000000 node declares 1GB of RAM (ending at 0xBFFFFFFF), but
this CMA region is hardcoded to start at 0xC0000000, which falls outside
that default 1GB range.

> +			size = <0 0x3c000000>;
> +			linux,cma-default;
> +			reusable;
> +		};
> +	};
[ ... ]
> +/* 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>;
> +	non-removable;

[Severity: High]
Will this configuration prevent the WiFi module from initializing?

Since usdhc3 is marked non-removable, the MMC driver will attempt to probe
the SDIO bus immediately during boot. Because the pinctrl_wifi group
(containing the initialization GPIOs) is bound to the MMC driver here, user
space cannot claim or toggle these pins to power up the WiFi chip.

The probe may fail permanently since the chip is unpowered during the kernel
probe. Could this be modeled using mmc-pwrseq-simple so the kernel handles
the power sequence automatically before probing?

> +	status = "okay";
> +
> +	brcmf: wifi@1 {
> +		compatible = "brcm,bcm4329-fmac";
> +		reg = <1>;
> +	};
> +};

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