From: sashiko-bot@kernel.org
To: genevieve.chan@altera.com
Cc: conor+dt@kernel.org, devicetree@vger.kernel.org, robh@kernel.org
Subject: Re: [PATCH 2/2] arm64: dts: socfpga: agilex: add Agilex7F SoCDK multi-QSPI board
Date: Mon, 14 Sep 2026 02:58:45 +0000 [thread overview]
Message-ID: <20260914025846.508551F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260914025052.14354-3-genevieve.chan@altera.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Duplicate MTD partition labels across multiple QSPI flashes will cause naming collisions.
- [Low] Incorrect alphabetical sorting in the Makefile.
--
commit 43a050c9384cc9ad44970b1e567a46311025cd69
Author: Genevieve Chan <genevieve.chan@altera.com>
arm64: dts: socfpga: agilex: add Agilex7F SoCDK multi-QSPI board
This patch adds a board device tree for the Agilex7F SoCDK with multi-QSPI
support. It describes four Micron MT25QU02G flashes on chip selects 0-3 based
on the socfpga_agilex.dtsi include.
> diff --git a/arch/arm64/boot/dts/intel/Makefile b/arch/arm64/boot/dts/intel/Makefile
> index 270c70fdf084b..9298ab8b93142 100644
> --- a/arch/arm64/boot/dts/intel/Makefile
> +++ b/arch/arm64/boot/dts/intel/Makefile
> @@ -10,5 +10,6 @@ dtb-$(CONFIG_ARCH_INTEL_SOCFPGA) += socfpga_agilex_n6000.dtb \
> socfpga_agilex5_socdk_nand.dtb \
> socfpga_agilex72_socdk.dtb \
> socfpga_agilex7m_socdk.dtb \
> + socfpga_agilex7f_socdk_multiqspi.dtb \
[Severity: Low]
Does this Makefile addition break alphabetical sorting?
The new entry socfpga_agilex7f_socdk_multiqspi.dtb under
dtb-$(CONFIG_ARCH_INTEL_SOCFPGA) is inserted after socfpga_agilex7m_socdk.dtb,
rather than before it.
> socfpga_n5x_socdk.dtb
> dtb-$(CONFIG_ARCH_KEEMBAY) += keembay-evm.dtb
> diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex7f_socdk_multiqspi.dts b/arch/arm64/boot/dts/intel/socfpga_agilex7f_socdk_multiqspi.dts
> new file mode 100644
> index 0000000000000..7d444a84fd67a
> --- /dev/null
> +++ b/arch/arm64/boot/dts/intel/socfpga_agilex7f_socdk_multiqspi.dts
[ ... ]
> + 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";
[Severity: Medium]
Will these duplicate partition labels cause naming collisions in the MTD
subsystem?
Since the device tree parses these four partitions (qspi_boot0 through
qspi_boot3) and registers them with the exact same label ("Boot and fpga
data") for flash@0 through flash@3, they will create duplicate MTD
partition names in the kernel (e.g., in /proc/mtd).
Userspace tools like mtd-utils that rely on finding MTD partitions by name
might be unable to distinguish between the physical chips. Could this lead
to data corruption if the wrong flash is updated?
> + reg = <0x0 0x10000000>;
> + };
> + };
> + };
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260914025052.14354-1-genevieve.chan@altera.com?part=2
prev parent reply other threads:[~2026-09-14 2:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-14 2:50 [PATCH 0/2] arm64: dts: socfpga: agilex: add Agilex7F SoCDK multi-QSPI board genevieve.chan
2026-09-14 2:50 ` [PATCH 1/2] dt-bindings: arm: altera: add Agilex7F SoCDK multi-QSPI compatible genevieve.chan
2026-09-15 10:49 ` Krzysztof Kozlowski
2026-09-29 13:42 ` Chan, Genevieve
2026-09-14 2:50 ` [PATCH 2/2] arm64: dts: socfpga: agilex: add Agilex7F SoCDK multi-QSPI board genevieve.chan
2026-09-14 2:58 ` sashiko-bot [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260914025846.508551F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=genevieve.chan@altera.com \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.