Re: [PATCH v2 08/11] ARM: dts: imx6ul: Add Variscite i.MX6UL board variants

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] dt: combinatorial explosion of board variants instead of dt overlays
--

commit 43bde4408af702619bbd79aa5184aabeb1e39f18
Author: Stefano Radaelli <stefano.r@variscite.com>

ARM: dts: imx6ul: Add Variscite i.MX6UL board variants

Add i.MX6UL board DTS files for VAR-SOM-6UL and DART-6UL with their
carrier, storage, wireless and audio options.

Compose each board description from the shared module, option and
carrier DTSI files added earlier in the series.

> diff --git a/arch/arm/boot/dts/nxp/imx/imx6ul-var-dart-emmc-sd-card-6ulcustomboard.dts b/arch/arm/boot/dts/nxp/imx/imx6ul-var-dart-emmc-sd-card-6ulcustomboard.dts
> new file mode 100644
> index 0000000000000..74b2ca1895c27
> --- /dev/null
> +++ b/arch/arm/boot/dts/nxp/imx/imx6ul-var-dart-emmc-sd-card-6ulcustomboard.dts
> @@ -0,0 +1,20 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2026 Variscite Ltd. - https://www.variscite.com
> + */
> +
> +/dts-v1/;
> +
> +#include "imx6ul.dtsi"
> +#include "imx6ul-var-dart.dtsi"
> +#include "imx6ul-imx6ull-var-dart-emmc.dtsi"
> +#include "imx6ul-imx6ull-var-dart-wm8904.dtsi"
> +#include "imx6ul-var-dart-6ulcustomboard.dtsi"
> +#include "imx6ul-imx6ull-var-dart-6ulcustomboard-sd-card.dtsi"
> +
> +/ {
> +	model = "Variscite DART-6UL with i.MX6UL, eMMC, SD card & WM8904 support on VAR-6ULCustomBoard";
> +	compatible = "variscite,dart-6ul-imx6ul-emmc-sd-card-6ulcustomboard",
> +		     "variscite,dart-6ul-imx6ul",
> +		     "fsl,imx6ul";

[Severity: Low]
Adding 90 top-level .dts files across the series to represent every possible
hardware permutation of storage, Wi-Fi, and audio modules creates an immense
maintenance burden, clutters the tree, and inflates the build configuration.

Instead of generating 30 distinct .dts files per SoC variant and embedding
component states (e.g., emmc-sd-card-wm8731) into the base machine
compatible property, standard modern Device Tree practice dictates defining
a base machine board and using Device Tree Source Overlays (.dtso) for
optional component variants.

Overloading the root compatible string with highly specific peripheral
configuration details appears to be an abuse of the machine identity
property.

Could this combinatorial explosion of board variants be avoided by using
device tree overlays?

> +};

[ ... ]

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