Re: [PATCH v4 2/3] ARM: dts: imx7d: add Variscite VAR-SOM-MX7 support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The `sw1a` regulator maximum voltage is set to 3.3V, which violates the i.MX7D core voltage limits (typically 1.0V, max 1.15V) and the PFUZE3000 SW1A hardware limit for this design (max 1.475V).
- [High] Deleting `fsl,sai-mclk-direction-output` prevents the SoC from outputting the required Master Clock (MCLK) to the WM8731 audio codec.
- [Medium] The `sd3-pwr-hog` GPIO hog on `gpio6 11` directly conflicts with the native `usdhc3` pinctrl configuration for `SD3_RESET_B`.
--

--- Patch [2]: [PATCH v4 2/3] ARM: dts: imx7d: add Variscite VAR-SOM-MX7 support ---
commit a699faaceb07c2b3521d089b94e7deba5e25dd8b
Author: Stefano Radaelli <stefano.r@variscite.com>

ARM: dts: imx7d: add Variscite VAR-SOM-MX7 support

Add device tree support for the Variscite VAR-SOM-MX7 system on module.
The module is based on the NXP i.MX7Dual SoC.

Link: https://variscite.com/system-on-module-som/i-mx-7/var-som-mx7/

> diff --git a/arch/arm/boot/dts/nxp/imx/imx7d-var-som-emmc.dtsi b/arch/arm/boot/dts/nxp/imx/imx7d-var-som-emmc.dtsi
> new file mode 100644
> --- /dev/null
> +++ b/arch/arm/boot/dts/nxp/imx/imx7d-var-som-emmc.dtsi
[ ... ]
> +&gpio6 {
> +	sd3-pwr-hog {
> +		gpio-hog;
> +		gpios = <11 0>;
> +		output-low;
> +		line-name = "sd3_pwr";
> +	};
> +};
[ ... ]
> +&iomuxc {
> +	pinctrl_usdhc3: usdhc3grp {
> +		fsl,pins = <
> +			MX7D_PAD_SD3_RESET_B__SD3_RESET_B	0x59

[Severity: Medium]
Does this GPIO hog conflict with the native usdhc3 pinctrl configuration
for SD3_RESET_B?

The sd3-pwr-hog statically claims gpio6 11, which corresponds to
MX7D_PAD_SD3_RESET_B. The pinctrl_usdhc3 later claims the exact same pad as
SD3_RESET_B in its native mode.

Could this cause a device tree resource conflict over the pad, and
potentially spuriously reset the eMMC during sleep transitions if the
pin reverts to the driven-low GPIO state?

> diff --git a/arch/arm/boot/dts/nxp/imx/imx7d-var-som-wm8731.dtsi b/arch/arm/boot/dts/nxp/imx/imx7d-var-som-wm8731.dtsi
> new file mode 100644
> --- /dev/null
> +++ b/arch/arm/boot/dts/nxp/imx/imx7d-var-som-wm8731.dtsi
[ ... ]
> +&sai1 {
> +	assigned-clock-rates = <0>, <36864000>;
> +	/delete-property/ fsl,sai-mclk-direction-output;
> +};

[Severity: High]
Does deleting the fsl,sai-mclk-direction-output property prevent the SoC
from outputting the required master clock to the WM8731 audio codec?

The WM8731 codec requires an MCLK to function. By removing this direction
property, the SAI block might configure the pad as an input, which would leave
the codec without a master clock from the SoC.

> diff --git a/arch/arm/boot/dts/nxp/imx/imx7d-var-som.dtsi b/arch/arm/boot/dts/nxp/imx/imx7d-var-som.dtsi
> new file mode 100644
> --- /dev/null
> +++ b/arch/arm/boot/dts/nxp/imx/imx7d-var-som.dtsi
[ ... ]
> +&i2c1 {
[ ... ]
> +	pfuze300: pmic@8 {
> +		compatible = "fsl,pfuze3000";
> +		reg = <0x08>;
> +
> +		regulators {
> +			sw1a_reg: sw1a {
> +				regulator-min-microvolt = <700000>;
> +				regulator-max-microvolt = <3300000>;

[Severity: High]
Does setting the sw1a maximum voltage to 3.3V violate the hardware limits
for the i.MX7D core voltage?

The sw1a regulator supplies the cpu0 and cpu1 cores. The PFUZE3000 SW1A limit
for this design is typically around 1.475V, and the absolute maximum rating
for the i.MX7D ARM cores is usually around 1.15V.

If a driver scales the core voltage up to 3.3V based on these boundaries,
could this result in hardware damage?

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