Re: [PATCH] arm64: dts: freescale: Add device tree definition for Cloos CBASE with i.MX8MM

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 6 potential
issues to consider:
- [High] arm64: dts: freescale: usdhc2 fails probe due to disabled
  reg_usdhc2_vqmmc
- [Medium] arm64: dts: freescale: missing Makefile entry for
  imx8mm-cbase.dtb
- [Medium] arm64: dts: freescale: lcdif enabled without mipi_dsi or
  display bridge
- [Medium] arm64: dts: freescale: undocumented compatibles and missing
  lm77 OF table
- [Low] arm64: dts: freescale: decimal unit-address port@10 for reg =
  <10>
- [Low] arm64: dts: freescale: flexspi left enabled after deleting
  flash0 node
--

commit ed8bce86f8c6ce432aef83c22f5cd48f6151d1c7
Author: Lukasz Majewski <lukma@nabladev.com>

arm64: dts: freescale: Add device tree definition for Cloos CBASE with i.MX8MM

This commit adds the device tree source for the Cloos CBASE board based on
the i.MX8MM TQMa8MQML system-on-module.

> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-cbase.dts b/arch/arm64/boot/dts/freescale/imx8mm-cbase.dts
> new file mode 100644
> index 0000000000000..0bbd724f3aabc
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-cbase.dts
> @@ -0,0 +1,577 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright 2022 Fabio Estevam <festevam@denx.de>
> + * Copyright 2026 Lukasz Majewski <lukma@nabladev.com>
> + */
> +
> +/dts-v1/;
> +
> +#include "imx8mm-tqma8mqml.dtsi"
> +
> +/ {
> +	model = "Cloos i.MX8MM CBASE board";
> +	compatible = "cloos,imx8mm-cbase", "tq,imx8mm-tqma8mqml", "fsl,imx8mm";

[Severity: Medium]
Should arch/arm64/boot/dts/freescale/Makefile also add
dtb-$(CONFIG_ARCH_MXC) += imx8mm-cbase.dtb?  Without that entry, kbuild
never compiles imx8mm-cbase.dts during make dtbs or make dtbs_check.

[ ... ]

> +				port@9 {
> +					reg = <9>;
> +					label = "lan-sfp1";
> +					phy-mode = "sgmii";
> +					sfp = <&sfp_top>;
> +					managed = "in-band-status";
> +				};
> +
> +				port@10 {
> +					reg = <10>;
> +					label = "lan-sfp2";
> +					phy-mode = "sgmii";
> +					sfp = <&sfp_bot>;
> +					managed = "in-band-status";
> +				};

[Severity: Low]
Should port@10 be named port@a to match reg = <10>?  Unit-addresses in node
names are hexadecimal, so port@10 triggers a dtc unit_address_vs_reg warning
and fails dtbs_check against ethernet-switch.yaml.

[ ... ]

> +&i2c2 {
> +	clock-frequency = <100000>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_i2c2>;
> +	status = "okay";
> +
> +	onewire@18 {
> +		compatible = "maxim,ds2484";
> +		reg = <0x18>;
> +	};
> +
> +	temp@49 {
> +		compatible = "national,lm77";
> +		reg = <0x49>;
> +	};
> +};

[Severity: Medium]
Will temp@49 fail module autoloading and schema validation?

drivers/hwmon/lm77.c only defines an i2c_device_id table and has no
of_device_id table, while i2c_device_uevent() emits an OF modalias for DT
nodes, so the lm77 module will not autoload when CONFIG_SENSORS_LM77=m.
In addition, neither "national,lm77" (nor the node name temp@49 instead of
temperature-sensor@49) nor the board compatible "cloos,imx8mm-cbase" is
documented in the Devicetree bindings, which causes make dtbs_check to fail.

[ ... ]

> +&lcdif {
> +	status = "okay";
> +};

[Severity: Medium]
Why is lcdif enabled here when mipi_dsi remains disabled and no display
bridge or panel is defined?

In imx8mm.dtsi, lcdif's output endpoint connects to mipi_dsi, which defaults
to status = "disabled".  During boot, mxsfb_probe() -> mxsfb_load() ->
mxsfb_attach_bridge() fails to find an enabled remote bridge or panel and
aborts probe with -ENODEV ("Cannot connect bridge").

[ ... ]

> +&usdhc2 {
> +	assigned-clocks = <&clk IMX8MM_CLK_USDHC2>;
> +	assigned-clock-rates = <400000000>;
> +	assigned-clock-parents = <&clk IMX8MM_SYS_PLL1_400M>;
> +	pinctrl-names = "default", "state_100mhz", "state_200mhz";
> +	pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
> +	pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
> +	pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
> +	bus-width = <4>;
> +	cd-gpios = <&gpio2 12 GPIO_ACTIVE_LOW>;
> +	disable-wp;
> +	no-mmc;
> +	no-sdio;
> +	sd-uhs-sdr104;
> +	sd-uhs-ddr50;
> +	vmmc-supply = <&reg_usdhc2_vmmc>;
> +	status = "okay";
> +};

[Severity: High]
Does usdhc2 fail to probe because reg_usdhc2_vqmmc is left disabled?

imx8mm-tqma8mqml.dtsi sets vqmmc-supply = <&reg_usdhc2_vqmmc> on usdhc2,
where reg_usdhc2_vqmmc has status = "disabled":

arch/arm64/boot/dts/freescale/imx8mm-tqma8mqml.dtsi:
	reg_usdhc2_vqmmc: regulator-usdhc2-vqmmc {
		compatible = "regulator-gpio";
		...
		vin-supply = <&ldo5_reg>;
		status = "disabled";
	};

Because imx8mm-cbase.dts does not enable reg_usdhc2_vqmmc,
sdhci_esdhc_imx_probe() -> mmc_regulator_get_supply() ->
of_regulator_dev_lookup() finds the disabled DT node with no registered
regulator device and returns -EPROBE_DEFER permanently, leaving the SD card
slot unusable.

[ ... ]

> +/* SPI-NOR memory is not mounted on the used SoM */
> +/delete-node/ &flash0;

[Severity: Low]
Should &flexspi be disabled instead of only deleting &flash0?

imx8mm-tqma8mqml.dtsi sets status = "okay" on &flexspi, so deleting only the
child flash0 node leaves the FlexSPI controller enabled to claim its QSPI
pins, IRQ, and clocks in nxp_fspi_probe() with no flash attached.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261110150546.1535950-1-lukma@nabladev.com?part=1