Re: [PATCH v2 2/2] arm64: dts: socfpga: agilex: add Agilex SoCDK multi-QSPI board

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] mtd: duplicate partition labels across multi-QSPI flashes
- [Low] dts: excessive duplication of SoCDK baseboard configuration
--

commit e53835bafbaf52462a16d7064f169ecf5af12f67
Author: Genevieve Chan <genevieve.chan@altera.com>

arm64: dts: socfpga: agilex: add Agilex SoCDK multi-QSPI board

This commit adds a new device tree for the Agilex SoCDK multi-QSPI
daughter board, which replaces the single QSPI flash with four
micron flashes. The board is otherwise identical to the standard SoCDK.

> diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex_socdk_multiqspi.dts b/arch/arm64/boot/dts/intel/socfpga_agilex_socdk_multiqspi.dts
> new file mode 100644
> --- /dev/null
> +++ b/arch/arm64/boot/dts/intel/socfpga_agilex_socdk_multiqspi.dts
> @@ -0,0 +1,213 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2026, Intel Corporation
> + */
> +#include "socfpga_agilex.dtsi"
> +
> +/ {
> +	model = "SoCFPGA Agilex SoCDK multi-QSPI daughter board";
> +	compatible = "intel,socfpga-agilex-socdk-multiqspi", "intel,socfpga-agilex";
> +
> +	aliases {
> +		serial0 = &uart0;
> +		ethernet0 = &gmac0;
> +		ethernet1 = &gmac1;
> +		ethernet2 = &gmac2;
> +	};

[Severity: Low]
This isn't a bug, but there appears to be a lot of duplicated baseboard
configuration here. The commit message notes the board is otherwise
identical to the SoCDK, but over 100 lines of baseboard definitions like
these aliases, memory, LEDs, Ethernet MAC, MMC, and UART are copied
directly from the socfpga_agilex_socdk device tree.

Would it be better to extract this shared configuration into a common
socfpga_agilex_socdk.dtsi to prevent the board definitions from drifting
out of sync over time?

[ ... ]

> +	flash@0 {
> +		compatible = "micron,mt25qu02g", "jedec,spi-nor";
> +		reg = <0>;

[ ... ]

> +		partitions {
> +			compatible = "fixed-partitions";
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +
> +			qspi_boot0: partition@0 {
> +				label = "Boot and fpga data";
> +				reg = <0x0 0x10000000>;
> +			};
> +		};
> +	};
> +
> +	flash@1 {
> +		compatible = "micron,mt25qu02g", "jedec,spi-nor";
> +		reg = <1>;

[ ... ]

> +		partitions {
> +			compatible = "fixed-partitions";
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +
> +			qspi_boot1: partition@0 {
> +				label = "Boot and fpga data";
> +				reg = <0x0 0x10000000>;
> +			};
> +		};
> +	};

[Severity: Medium]
Is it intentional to use the exact same partition label for flash@0, flash@1,
flash@2, and flash@3?

When the device tree is parsed at boot, the Linux MTD subsystem uses this
label to identify the partition to userspace. Having four partitions with
identical names breaks name-based access like /dev/mtd/by-name/ or root=mtd:
because userspace tools will only be able to uniquely address the first
matched partition. 

Additionally, since flashes on CS1 through CS3 are typically not boot
flashes, the shared label could be misleading. Could these labels be
made unique for each individual flash?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261006025418.31931-1-genevieve.chan@altera.com?part=2