Re: [PATCH v2 2/2] arm64: dts: agilex5: add support for debug daughter card
From: Dinh Nguyen
Date: Mon May 25 2026 - 22:44:25 EST
From sashiko gemini-3.1-pro-review:
On 5/22/26 03:34, Adrian Ng Ho Yin wrote:
The debug daughter card replaces gmac2 with gmac0 for Ethernet, leaves
gpio0 unrouted, and adds a Microchip 25AA128 16 KByte SPI EEPROM on spi0.
Remove the dmas/dma-names properties from spi0: CONFIG_DW_AXI_DMAC is
not enabled in the platform defconfig, so retaining them would stall the
SPI driver in probe deferral. Set spi-max-frequency to 500 kHz to match
the signal integrity constraints of this board.
Signed-off-by: Niravkumar L Rabara <nirav.rabara@xxxxxxxxxx>
Signed-off-by: Adrian Ng Ho Yin <adrian.ho.yin.ng@xxxxxxxxxx>
---
arch/arm64/boot/dts/intel/Makefile | 1 +
.../dts/intel/socfpga_agilex5_socdk_debug.dts | 123 ++++++++++++++++++
2 files changed, 124 insertions(+)
create mode 100644 arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_debug.dts
diff --git a/arch/arm64/boot/dts/intel/Makefile b/arch/arm64/boot/dts/intel/Makefile
index 088a03b89c99..84982bf13ee5 100644
--- a/arch/arm64/boot/dts/intel/Makefile
+++ b/arch/arm64/boot/dts/intel/Makefile
@@ -6,6 +6,7 @@ dtb-$(CONFIG_ARCH_INTEL_SOCFPGA) += socfpga_agilex_n6000.dtb \
socfpga_agilex3_socdk.dtb \
socfpga_agilex5_socdk.dtb \
socfpga_agilex5_socdk_013b.dtb \
+ socfpga_agilex5_socdk_debug.dtb \
socfpga_agilex5_socdk_modular.dtb \
socfpga_agilex5_socdk_nand.dtb \
socfpga_agilex7m_socdk.dtb \
diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_debug.dts b/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_debug.dts
new file mode 100644
index 000000000000..e3fd2bf11688
--- /dev/null
+++ b/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_debug.dts
@@ -0,0 +1,123 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2023, Intel Corporation
+ */
+#include "socfpga_agilex5.dtsi"
+
+/ {
+ model = "SoCFPGA Agilex5 SoCDK - debug daughter card";
+ compatible = "intel,socfpga-agilex5-socdk-debug", "intel,socfpga-agilex5";
+
+ aliases {
+ serial0 = &uart0;
+ ethernet0 = &gmac0;
+ ethernet1 = &gmac1;
+ ethernet2 = &gmac2;
+ i3c0 = &i3c0;
+ i3c1 = &i3c1;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led-0 {
+ label = "hps_led0";
+ gpios = <&porta 11 GPIO_ACTIVE_HIGH>;
Isn't this in GPIO0? And since you're not enabling gpio0, wouldn't this lead to a infinite probe deferral?
+ };
+
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ /* We expect the bootloader to fill in the reg */
+ reg = <0x0 0x80000000 0x0 0x0>;
+ };
+};
+
+&gmac0 {
+ status = "okay";
+ phy-mode = "rgmii"; /* TX/RX clock delays provided by Agilex5 I/O hardware */
+ phy-handle = <&emac0_phy0>;
+ max-frame-size = <9000>;
+ mdio0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dwmac-mdio";
+ emac0_phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+ };
+};
+
+&gpio1 {
+ status = "okay";
+};
+
+&osc1 {
+ clock-frequency = <25000000>;
+};
+
+&qspi {
+ status = "okay";
+ flash@0 {
+ compatible = "micron,mt25qu02g", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <100000000>;
+ m25p,fast-read;
+ cdns,read-delay = <2>;
+ cdns,tshsl-ns = <50>;
+ cdns,tsd2d-ns = <50>;
+ cdns,tchsh-ns = <4>;
+ cdns,tslch-ns = <4>;
+ spi-tx-bus-width = <4>;
+ spi-rx-bus-width = <4>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ qspi_boot: partition@0 {
+ label = "u-boot";
+ reg = <0x0 0x04200000>;
+ };
+
+ root: partition@4200000 {
+ label = "root";
+ reg = <0x04200000 0x0be00000>;
+ };
+ };
+ };
+};
+
+&spi0 {
+ status = "okay";
+ /delete-property/ dmas;
+ /delete-property/ dma-names;
I don't think it's correct to modify a hardware description to work around a software configuration issue. The Device Tree should describe the physical hardware. If the physical DMA lines exist, deleting these properties to bypass the CONFIG_DW_AXI_DMAC Linux defconfig issue violates that principle.
Would it be better to retain the DMA properties and resolve the issue by either enabling the required DMA driver in the defconfig or ensuring the SPI driver gracefully falls back to PIO mode?
+ eeprom@0 {
+ compatible = "atmel,at25";
Since the commit message specifies the chip is a Microchip 25AA128, should this include the vendor-specific compatible string as the primary match (e.g., "microchip,25aa128", "atmel,at25")? The generic "atmel,at25" string without a specific model is deprecated for new device trees according to the at25 bindings.
Dinh