Re: [PATCH 2/2] arm64: dts: nuvoton: Add NuMaker board

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The NuMaker carrier board device tree fails to define its own `model` and `compatible` properties, incorrectly inheriting them from the included SoM device tree.
--

--- Patch [2]: [PATCH 2/2] arm64: dts: nuvoton: Add NuMaker board ---
commit ebe82dc4f8c0ba0308823c13c0ed25751cfbed16
Author: Miquel Raynal <[email protected]>

arm64: dts: nuvoton: Add NuMaker board

This patch adds device tree support for the NuMaker carrier board, which
uses the Nuvoton MA35D SoC on the NuMaker SoM. It creates a new DTS file
that includes the SoM description and adds a node for the SPI NAND connected
to the Quad SPI controller.

[ ... ]

> diff --git a/arch/arm64/boot/dts/nuvoton/ma35d1-numaker.dts b/arch/arm64/boot/dts/nuvoton/ma35d1-numaker.dts
> new file mode 100644
> index 0000000000000..01f1f800aef8d
> --- /dev/null
> +++ b/arch/arm64/boot/dts/nuvoton/ma35d1-numaker.dts
> @@ -0,0 +1,37 @@
> +// SPDX-License-Identifier: GPL-2.0-only OR MIT
> +/*
> + * Copyright (C) 2025 Bootlin
> + * Author: Miquel Raynal <[email protected]>
> + */
> +
> +/dts-v1/;
> +#include "ma35d1-som-256m.dts"
> +

[Severity: Medium]
Should this file define its own root node with model and compatible properties?

Without an overriding root node here, this compiled DTB inherits the
identity strings of the included SoM device tree. Can this cause the
bootloader or kernel to misidentify the NuMaker carrier board as the bare
SoM?

> +&pinctrl {
> +	spi-grp {

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2