[PATCH 0/4] arm64: dts: socfpga: enable ethernet support for Agilex5

[PATCH 0/4] arm64: dts: socfpga: enable ethernet support for Agilex5

[Matthew Gerlach]

This patch set enables ethernet support for the Agilex5 family SOCFPGAs,
and specifically enables gmac2 on the Agilex5 SOCFPGA Premium Development Kit.

Patch 1 defines Agilex5 compatibility string in the device tree bindings.

Patch 2 defines the base gmac nodes it the Agilex5 DTSI.

Patch 3 enables gmac2 on the Agilex5 SOCFPGA Premium Development Kit.

Patch 4 add the new compatibility string to dwmac-socfpga.c.

Matthew Gerlach (2):
  dt-bindings: net: altr,socfpga-stmmac: Add compatible string for
    Agilex5
  arm64: dts: socfpga: agilex5: enable gmac2 on the Agilex5 dev kit

Mun Yew Tham (2):
  arm64: dts: Agilex5 Add gmac nodes to DTSI for Agilex5
  net: stmmac: dwmac-socfpga: Add xgmac support for Agilex5

 .../bindings/net/altr,socfpga-stmmac.yaml     |   9 +-
 .../arm64/boot/dts/intel/socfpga_agilex5.dtsi | 339 ++++++++++++++++++
 .../boot/dts/intel/socfpga_agilex5_socdk.dts  |  18 +
 .../ethernet/stmicro/stmmac/dwmac-socfpga.c   |   1 +
 4 files changed, 365 insertions(+), 2 deletions(-)

-- 
2.49.0

[PATCH 1/4] dt-bindings: net: altr,socfpga-stmmac: Add compatible string for Agilex5

[Matthew Gerlach]

Add compatible string for the Altera Agilex5 variant of the Synopsys DWC
XGMAC IP version 2.10.

Signed-off-by: Matthew Gerlach <matthew.gerlach@altera.com>
---
 .../devicetree/bindings/net/altr,socfpga-stmmac.yaml     | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml b/Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml
index ec34daff2aa0..6d5c31c891de 100644
--- a/Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml
+++ b/Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml
@@ -11,8 +11,8 @@ maintainers:
 
 description:
   This binding describes the Altera SOCFPGA SoC implementation of the
-  Synopsys DWMAC for the Cyclone5, Arria5, Stratix10, and Agilex7 families
-  of chips.
+  Synopsys DWMAC for the Cyclone5, Arria5, Stratix10, Agilex5 and Agilex7
+  families of chips.
   # TODO: Determine how to handle the Arria10 reset-name, stmmaceth-ocp, that
   # does not validate against net/snps,dwmac.yaml.
 
@@ -23,6 +23,7 @@ select:
         enum:
           - altr,socfpga-stmmac
           - altr,socfpga-stmmac-a10-s10
+          - altr,socfpga-stmmac-agilex5
 
   required:
     - compatible
@@ -42,6 +43,10 @@ properties:
           - const: altr,socfpga-stmmac-a10-s10
           - const: snps,dwmac-3.74a
           - const: snps,dwmac
+      - items:
+          - const: altr,socfpga-stmmac-agilex5
+          - const: snps,dwxgmac-2.10
+          - const: snps,dwxgmac
 
   clocks:
     minItems: 1
-- 
2.49.0

[PATCH 2/4] arm64: dts: Agilex5 Add gmac nodes to DTSI for Agilex5

[Matthew Gerlach]

From: Mun Yew Tham <mun.yew.tham@altera.com>

Add the base device tree nodes for gmac0, gmac1, and gmac2 to the DTSI
for the Agilex5 SOCFPGA.  Agilex5 has three Ethernet controllers based on
Synopsys DWC XGMAC IP version 2.10.

Signed-off-by: Mun Yew Tham <mun.yew.tham@altera.com>
Signed-off-by: Matthew Gerlach <matthew.gerlach@altera.com>
---
 .../arm64/boot/dts/intel/socfpga_agilex5.dtsi | 339 ++++++++++++++++++
 1 file changed, 339 insertions(+)

diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
index 7d9394a04302..83581e7a85ab 100644
--- a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
+++ b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
@@ -486,5 +486,344 @@ qspi: spi@108d2000 {
 			clocks = <&qspi_clk>;
 			status = "disabled";
 		};
+
+		gmac0: ethernet@10810000 {
+			compatible = "altr,socfpga-stmmac-agilex5",
+				     "snps,dwxgmac-2.10",
+				     "snps,dwxgmac";
+			reg = <0x10810000 0x3500>;
+			interrupts = <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "macirq";
+			resets = <&rst EMAC0_RESET>, <&rst EMAC0_OCP_RESET>;
+			reset-names = "stmmaceth", "ahb";
+			clocks = <&clkmgr AGILEX5_EMAC0_CLK>,
+				 <&clkmgr AGILEX5_EMAC_PTP_CLK>;
+			clock-names = "stmmaceth", "ptp_ref";
+			mac-address = [00 00 00 00 00 00];
+			tx-fifo-depth = <32768>;
+			rx-fifo-depth = <16384>;
+			snps,multicast-filter-bins = <64>;
+			snps,perfect-filter-entries = <64>;
+			snps,axi-config = <&stmmac_axi_emac0_setup>;
+			snps,mtl-rx-config = <&mtl_rx_emac0_setup>;
+			snps,mtl-tx-config = <&mtl_tx_emac0_setup>;
+			snps,pbl = <32>;
+			snps,tso;
+			altr,sysmgr-syscon = <&sysmgr 0x44 0>;
+			snps,clk-csr = <0>;
+			status = "disabled";
+
+			stmmac_axi_emac0_setup: stmmac-axi-config {
+				snps,wr_osr_lmt = <31>;
+				snps,rd_osr_lmt = <31>;
+				snps,blen = <0 0 0 32 16 8 4>;
+			};
+
+			mtl_rx_emac0_setup: rx-queues-config {
+				snps,rx-queues-to-use = <8>;
+				snps,rx-sched-sp;
+				queue0 {
+					snps,dcb-algorithm;
+					snps,map-to-dma-channel = <0x0>;
+				};
+				queue1 {
+					snps,dcb-algorithm;
+					snps,map-to-dma-channel = <0x1>;
+				};
+				queue2 {
+					snps,dcb-algorithm;
+					snps,map-to-dma-channel = <0x2>;
+				};
+				queue3 {
+					snps,dcb-algorithm;
+					snps,map-to-dma-channel = <0x3>;
+				};
+				queue4 {
+					snps,dcb-algorithm;
+					snps,map-to-dma-channel = <0x4>;
+				};
+				queue5 {
+					snps,dcb-algorithm;
+					snps,map-to-dma-channel = <0x5>;
+				};
+				queue6 {
+					snps,dcb-algorithm;
+					snps,map-to-dma-channel = <0x6>;
+				};
+				queue7 {
+					snps,dcb-algorithm;
+					snps,map-to-dma-channel = <0x7>;
+				};
+			};
+
+			mtl_tx_emac0_setup: tx-queues-config {
+				snps,tx-queues-to-use = <8>;
+				snps,tx-sched-wrr;
+				queue0 {
+					snps,weight = <0x09>;
+					snps,dcb-algorithm;
+				};
+				queue1 {
+					snps,weight = <0x0A>;
+					snps,dcb-algorithm;
+				};
+				queue2 {
+					snps,weight = <0x0B>;
+					snps,coe-unsupported;
+					snps,dcb-algorithm;
+				};
+				queue3 {
+					snps,weight = <0x0C>;
+					snps,coe-unsupported;
+					snps,dcb-algorithm;
+				};
+				queue4 {
+					snps,weight = <0x0D>;
+					snps,coe-unsupported;
+					snps,dcb-algorithm;
+				};
+				queue5 {
+					snps,weight = <0x0E>;
+					snps,coe-unsupported;
+					snps,dcb-algorithm;
+				};
+				queue6 {
+					snps,weight = <0x0F>;
+					snps,coe-unsupported;
+					snps,dcb-algorithm;
+				};
+				queue7 {
+					snps,weight = <0x10>;
+					snps,coe-unsupported;
+					snps,dcb-algorithm;
+				};
+			};
+		};
+
+		gmac1: ethernet@10820000 {
+			compatible = "altr,socfpga-stmmac-agilex5",
+				     "snps,dwxgmac-2.10",
+				     "snps,dwxgmac";
+			reg = <0x10820000 0x3500>;
+			interrupts = <GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "macirq";
+			resets = <&rst EMAC1_RESET>, <&rst EMAC1_OCP_RESET>;
+			reset-names = "stmmaceth", "ahb";
+			clocks = <&clkmgr AGILEX5_EMAC1_CLK>,
+				 <&clkmgr AGILEX5_EMAC_PTP_CLK>;
+			clock-names = "stmmaceth", "ptp_ref";
+			mac-address = [00 00 00 00 00 00];
+			tx-fifo-depth = <32768>;
+			rx-fifo-depth = <16384>;
+			snps,multicast-filter-bins = <64>;
+			snps,perfect-filter-entries = <64>;
+			snps,axi-config = <&stmmac_axi_emac1_setup>;
+			snps,mtl-rx-config = <&mtl_rx_emac1_setup>;
+			snps,mtl-tx-config = <&mtl_tx_emac1_setup>;
+			snps,pbl = <32>;
+			snps,tso;
+			altr,sysmgr-syscon = <&sysmgr 0x48 0>;
+			snps,clk-csr = <0>;
+			status = "disabled";
+
+			stmmac_axi_emac1_setup: stmmac-axi-config {
+				snps,wr_osr_lmt = <31>;
+				snps,rd_osr_lmt = <31>;
+				snps,blen = <0 0 0 32 16 8 4>;
+			};
+
+			mtl_rx_emac1_setup: rx-queues-config {
+				snps,rx-queues-to-use = <8>;
+				snps,rx-sched-sp;
+				queue0 {
+					snps,dcb-algorithm;
+					snps,map-to-dma-channel = <0x0>;
+				};
+				queue1 {
+					snps,dcb-algorithm;
+					snps,map-to-dma-channel = <0x1>;
+				};
+				queue2 {
+					snps,dcb-algorithm;
+					snps,map-to-dma-channel = <0x2>;
+				};
+				queue3 {
+					snps,dcb-algorithm;
+					snps,map-to-dma-channel = <0x3>;
+				};
+				queue4 {
+					snps,dcb-algorithm;
+					snps,map-to-dma-channel = <0x4>;
+				};
+				queue5 {
+					snps,dcb-algorithm;
+					snps,map-to-dma-channel = <0x5>;
+				};
+				queue6 {
+					snps,dcb-algorithm;
+					snps,map-to-dma-channel = <0x6>;
+				};
+				queue7 {
+					snps,dcb-algorithm;
+					snps,map-to-dma-channel = <0x7>;
+				};
+			};
+
+			mtl_tx_emac1_setup: tx-queues-config {
+				snps,tx-queues-to-use = <8>;
+				snps,tx-sched-wrr;
+				queue0 {
+					snps,weight = <0x09>;
+					snps,dcb-algorithm;
+				};
+				queue1 {
+					snps,weight = <0x0A>;
+					snps,dcb-algorithm;
+				};
+				queue2 {
+					snps,weight = <0x0B>;
+					snps,coe-unsupported;
+					snps,dcb-algorithm;
+				};
+				queue3 {
+					snps,weight = <0x0C>;
+					snps,coe-unsupported;
+					snps,dcb-algorithm;
+				};
+				queue4 {
+					snps,weight = <0x0D>;
+					snps,coe-unsupported;
+					snps,dcb-algorithm;
+				};
+				queue5 {
+					snps,weight = <0x0E>;
+					snps,coe-unsupported;
+					snps,dcb-algorithm;
+				};
+				queue6 {
+					snps,weight = <0x0F>;
+					snps,coe-unsupported;
+					snps,dcb-algorithm;
+				};
+				queue7 {
+					snps,weight = <0x10>;
+					snps,coe-unsupported;
+					snps,dcb-algorithm;
+				};
+			};
+		};
+
+		gmac2: ethernet@10830000 {
+			compatible = "altr,socfpga-stmmac-agilex5",
+				     "snps,dwxgmac-2.10",
+				     "snps,dwxgmac";
+			reg = <0x10830000 0x3500>;
+			interrupts = <GIC_SPI 224 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "macirq";
+			resets = <&rst EMAC2_RESET>, <&rst EMAC2_OCP_RESET>;
+			reset-names = "stmmaceth", "ahb";
+			clocks = <&clkmgr AGILEX5_EMAC2_CLK>,
+				 <&clkmgr AGILEX5_EMAC_PTP_CLK>;
+			clock-names = "stmmaceth", "ptp_ref";
+			mac-address = [00 00 00 00 00 00];
+			tx-fifo-depth = <32768>;
+			rx-fifo-depth = <16384>;
+			snps,multicast-filter-bins = <64>;
+			snps,perfect-filter-entries = <64>;
+			snps,axi-config = <&stmmac_axi_emac2_setup>;
+			snps,mtl-rx-config = <&mtl_rx_emac2_setup>;
+			snps,mtl-tx-config = <&mtl_tx_emac2_setup>;
+			snps,pbl = <32>;
+			snps,tso;
+			altr,sysmgr-syscon = <&sysmgr 0x4c 0>;
+			snps,clk-csr = <0>;
+			status = "disabled";
+
+			stmmac_axi_emac2_setup: stmmac-axi-config {
+				snps,wr_osr_lmt = <31>;
+				snps,rd_osr_lmt = <31>;
+				snps,blen = <0 0 0 32 16 8 4>;
+			};
+
+			mtl_rx_emac2_setup: rx-queues-config {
+				snps,rx-queues-to-use = <8>;
+				snps,rx-sched-sp;
+				queue0 {
+					snps,dcb-algorithm;
+					snps,map-to-dma-channel = <0x0>;
+				};
+				queue1 {
+					snps,dcb-algorithm;
+					snps,map-to-dma-channel = <0x1>;
+				};
+				queue2 {
+					snps,dcb-algorithm;
+					snps,map-to-dma-channel = <0x2>;
+				};
+				queue3 {
+					snps,dcb-algorithm;
+					snps,map-to-dma-channel = <0x3>;
+				};
+				queue4 {
+					snps,dcb-algorithm;
+					snps,map-to-dma-channel = <0x4>;
+				};
+				queue5 {
+					snps,dcb-algorithm;
+					snps,map-to-dma-channel = <0x5>;
+				};
+				queue6 {
+					snps,dcb-algorithm;
+					snps,map-to-dma-channel = <0x6>;
+				};
+				queue7 {
+					snps,dcb-algorithm;
+					snps,map-to-dma-channel = <0x7>;
+				};
+			};
+
+			mtl_tx_emac2_setup: tx-queues-config {
+				snps,tx-queues-to-use = <8>;
+				snps,tx-sched-wrr;
+				queue0 {
+					snps,weight = <0x09>;
+					snps,dcb-algorithm;
+				};
+				queue1 {
+					snps,weight = <0x0A>;
+					snps,dcb-algorithm;
+				};
+				queue2 {
+					snps,weight = <0x0B>;
+					snps,coe-unsupported;
+					snps,dcb-algorithm;
+				};
+				queue3 {
+					snps,weight = <0x0C>;
+					snps,coe-unsupported;
+					snps,dcb-algorithm;
+				};
+				queue4 {
+					snps,weight = <0x0D>;
+					snps,coe-unsupported;
+					snps,dcb-algorithm;
+				};
+				queue5 {
+					snps,weight = <0x0E>;
+					snps,coe-unsupported;
+					snps,dcb-algorithm;
+				};
+				queue6 {
+					snps,weight = <0x0F>;
+					snps,coe-unsupported;
+					snps,dcb-algorithm;
+				};
+				queue7 {
+					snps,weight = <0x10>;
+					snps,coe-unsupported;
+					snps,dcb-algorithm;
+				};
+			};
+		};
 	};
 };
-- 
2.49.0

[PATCH 3/4] arm64: dts: socfpga: agilex5: enable gmac2 on the Agilex5 dev kit

[Matthew Gerlach]

Enable gmac2 on the Agilex5 SOCFGPA Development Kit. The MAC is connected
to a RGMII PHY on a daughter card. The necessary clock delays are
implemented between the MAC and PHY by the IO ring of the Agilex5.

Signed-off-by: Matthew Gerlach <matthew.gerlach@altera.com>
---
 .../boot/dts/intel/socfpga_agilex5_socdk.dts   | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk.dts b/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk.dts
index d3b913b7902c..5436646ec7ad 100644
--- a/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk.dts
+++ b/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk.dts
@@ -10,6 +10,9 @@ / {
 
 	aliases {
 		serial0 = &uart0;
+		ethernet0 = &gmac0;
+		ethernet1 = &gmac1;
+		ethernet2 = &gmac2;
 	};
 
 	chosen {
@@ -37,6 +40,21 @@ &gpio0 {
 	status = "okay";
 };
 
+&gmac2 {
+	status = "okay";
+	phy-mode = "rgmii";	/* Delays implemented by the IO ring of the Agilex5 SOCFPGA. */
+	phy-handle = <&emac2_phy0>;
+	max-frame-size = <9000>;
+	mdio0 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "snps,dwmac-mdio";
+		emac2_phy0: ethernet-phy@0 {
+			reg = <0>;
+		};
+	};
+};
+
 &gpio1 {
 	status = "okay";
 };
-- 
2.49.0

[PATCH 4/4] net: stmmac: dwmac-socfpga: Add xgmac support for Agilex5

[Matthew Gerlach]

From: Mun Yew Tham <mun.yew.tham@altera.com>

Add support for Agilex5 compatible value.

Signed-off-by: Mun Yew Tham <mun.yew.tham@altera.com>
Signed-off-by: Matthew Gerlach <matthew.gerlach@altera.com>
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
index 72b50f6d72f4..01dd0cf0923c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -515,6 +515,7 @@ static const struct socfpga_dwmac_ops socfpga_gen10_ops = {
 static const struct of_device_id socfpga_dwmac_match[] = {
 	{ .compatible = "altr,socfpga-stmmac", .data = &socfpga_gen5_ops },
 	{ .compatible = "altr,socfpga-stmmac-a10-s10", .data = &socfpga_gen10_ops },
+	{ .compatible = "altr,socfpga-stmmac-agilex5", .data = &socfpga_gen10_ops },
 	{ }
 };
 MODULE_DEVICE_TABLE(of, socfpga_dwmac_match);
-- 
2.49.0

Re: [PATCH 3/4] arm64: dts: socfpga: agilex5: enable gmac2 on the Agilex5 dev kit

[Andrew Lunn]

> +&gmac2 {
> +	status = "okay";
> +	phy-mode = "rgmii";	/* Delays implemented by the IO ring of the Agilex5 SOCFPGA. */

Please could you explain in more details what this means.

The normal meaning for 'rgmii' is that the PCB implements the delay. I
just want to fully understand what this IO ring is, and if it is part
of the PCB.

> +	phy-handle = <&emac2_phy0>;
> +	max-frame-size = <9000>;
> +	mdio0 {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		compatible = "snps,dwmac-mdio";
> +		emac2_phy0: ethernet-phy@0 {
> +			reg = <0>;
> +		};

Please add a newline in here to separate the inner node from the
rest.

    Andrew

---
pw-bot: cr

Re: [PATCH 3/4] arm64: dts: socfpga: agilex5: enable gmac2 on the Agilex5 dev kit

[Matthew Gerlach]

On 7/14/25 10:25 AM, Andrew Lunn wrote:
> > +&gmac2 {
> > +	status = "okay";
> > +	phy-mode = "rgmii";	/* Delays implemented by the IO ring of the Agilex5 SOCFPGA. */
>
> Please could you explain in more details what this means.
>
> The normal meaning for 'rgmii' is that the PCB implements the delay. I
> just want to fully understand what this IO ring is, and if it is part
> of the PCB.

The IO ring is the logic in the Agilex5 that controls the pins on the 
chip. It is this logic that sits between the MAC IP in the Agilex5 and 
the pins connected to the PCB that is inserting the necessary delays. 
Technically the PCB is not implementing the delays, but the "wires" 
between the MAC and the external pins of the Agilex5 are implementing 
the delay. It seems to me that "rgmii" is a more accurate description of 
the hardware than "rgmii-id" in this case.

>
> > +	phy-handle = <&emac2_phy0>;
> > +	max-frame-size = <9000>;
> > +	mdio0 {
> > +		#address-cells = <1>;
> > +		#size-cells = <0>;
> > +		compatible = "snps,dwmac-mdio";
> > +		emac2_phy0: ethernet-phy@0 {
> > +			reg = <0>;
> > +		};
>
> Please add a newline in here to separate the inner node from the
> rest.
>
>      Andrew

I will add a newline before the emac2_phy0 node as suggested in v2.

Thanks for the feedback,
Matthew Gerlach
>
> ---
> pw-bot: cr

Re: [PATCH 3/4] arm64: dts: socfpga: agilex5: enable gmac2 on the Agilex5 dev kit

[Andrew Lunn]

On Mon, Jul 14, 2025 at 11:09:33AM -0700, Matthew Gerlach wrote:
> 
> 
> On 7/14/25 10:25 AM, Andrew Lunn wrote:
> > > +&gmac2 {
> > > +	status = "okay";
> > > +	phy-mode = "rgmii";	/* Delays implemented by the IO ring of the Agilex5 SOCFPGA. */
> > 
> > Please could you explain in more details what this means.
> > 
> > The normal meaning for 'rgmii' is that the PCB implements the delay. I
> > just want to fully understand what this IO ring is, and if it is part
> > of the PCB.
> 
> The IO ring is the logic in the Agilex5 that controls the pins on the chip.
> It is this logic that sits between the MAC IP in the Agilex5 and the pins
> connected to the PCB that is inserting the necessary delays. Technically the
> PCB is not implementing the delays, but the "wires" between the MAC and the
> external pins of the Agilex5 are implementing the delay. It seems to me that
> "rgmii" is a more accurate description of the hardware than "rgmii-id" in
> this case.

Is this delay hard coded, physically impossible to be disabled? A
syntheses option? Can it be changed at run time? Is the IO ring under
the control of a pinctrl driver? Can i use the standard 'skew-delay'
DT property to control this delay?

For silicon, if the delay cannot be removed, we have MAC drivers masks
the phy-mode to indicate it has implemented the delay. The MAC driver
should also return -EINVAL for any other RGMII mode than rgmii-id,
because that is the only RGMII mode which is possible.

Since this is an FPGA, it is a bit more complex, so i want to fully
understand what is going on, what the different options are.

	Andrew

Re: [PATCH 3/4] arm64: dts: socfpga: agilex5: enable gmac2 on the Agilex5 dev kit

[Matthew Gerlach]

On 7/14/25 11:52 AM, Andrew Lunn wrote:
> On Mon, Jul 14, 2025 at 11:09:33AM -0700, Matthew Gerlach wrote:
> > 
> > 
> > On 7/14/25 10:25 AM, Andrew Lunn wrote:
> > > > +&gmac2 {
> > > > +	status = "okay";
> > > > +	phy-mode = "rgmii";	/* Delays implemented by the IO ring of the Agilex5 SOCFPGA. */
> > > 
> > > Please could you explain in more details what this means.
> > > 
> > > The normal meaning for 'rgmii' is that the PCB implements the delay. I
> > > just want to fully understand what this IO ring is, and if it is part
> > > of the PCB.
> > 
> > The IO ring is the logic in the Agilex5 that controls the pins on the chip.
> > It is this logic that sits between the MAC IP in the Agilex5 and the pins
> > connected to the PCB that is inserting the necessary delays. Technically the
> > PCB is not implementing the delays, but the "wires" between the MAC and the
> > external pins of the Agilex5 are implementing the delay. It seems to me that
> > "rgmii" is a more accurate description of the hardware than "rgmii-id" in
> > this case.
>
> Is this delay hard coded, physically impossible to be disabled? A
> syntheses option? Can it be changed at run time? Is the IO ring under
> the control of a pinctrl driver? Can i use the standard 'skew-delay'
> DT property to control this delay?
The delay is not hard coded. It is a synthesis option that can be 
disabled. The value cannot be changed at run time, and the IO ring is 
not under control of a pinctrl driver; so I don't think the standard 
'skew-delay' DT property can be used.
>
> For silicon, if the delay cannot be removed, we have MAC drivers masks
> the phy-mode to indicate it has implemented the delay. The MAC driver
> should also return -EINVAL for any other RGMII mode than rgmii-id,
> because that is the only RGMII mode which is possible.
The delay in the IO ring can be disabled, but implementing the delay in 
the IO ring allows for RGMII phys that don't implement the delay. 
Currently the driver, 
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c, and its bindings, 
Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml, allow 
all rgmii phy-modes.
>
> Since this is an FPGA, it is a bit more complex, so i want to fully
> understand what is going on, what the different options are.
In this particular instantiation, the hard MAC controller is directly 
connected to pins via the IO ring, and the FPGA is not involved.

Matthew Gerlach
>
> 	Andrew

Re: [PATCH 3/4] arm64: dts: socfpga: agilex5: enable gmac2 on the Agilex5 dev kit

[Andrew Lunn]

On Mon, Jul 14, 2025 at 03:29:21PM -0700, Matthew Gerlach wrote:
> 
> 
> On 7/14/25 11:52 AM, Andrew Lunn wrote:
> > On Mon, Jul 14, 2025 at 11:09:33AM -0700, Matthew Gerlach wrote:
> > > > > On 7/14/25 10:25 AM, Andrew Lunn wrote:
> > > > > +&gmac2 {
> > > > > +	status = "okay";
> > > > > +	phy-mode = "rgmii";	/* Delays implemented by the IO ring of the Agilex5 SOCFPGA. */
> > > > > > Please could you explain in more details what this means.
> > > > > > The normal meaning for 'rgmii' is that the PCB implements the
> > delay. I
> > > > just want to fully understand what this IO ring is, and if it is part
> > > > of the PCB.
> > > > The IO ring is the logic in the Agilex5 that controls the pins on
> > the chip.
> > > It is this logic that sits between the MAC IP in the Agilex5 and the pins
> > > connected to the PCB that is inserting the necessary delays. Technically the
> > > PCB is not implementing the delays, but the "wires" between the MAC and the
> > > external pins of the Agilex5 are implementing the delay. It seems to me that
> > > "rgmii" is a more accurate description of the hardware than "rgmii-id" in
> > > this case.
> > 
> > Is this delay hard coded, physically impossible to be disabled? A
> > syntheses option? Can it be changed at run time? Is the IO ring under
> > the control of a pinctrl driver? Can i use the standard 'skew-delay'
> > DT property to control this delay?

> The delay is not hard coded. It is a synthesis option that can be disabled.

Is there a register you can read which tells you if it is
enabled/disabled?

> The delay in the IO ring can be disabled, but implementing the delay in the
> IO ring allows for RGMII phys that don't implement the delay.

All RGMII PHYs which Linux support have the ability to do delays. And
we recommend the PHY does the delay, just to keep all systems the
same. There are a few exceptions, mostly because the MAC has hard
coded delays which cannot be disabled, but i guess 90% of systems have
the PHY doing the 2ns delays.

So, phy-mode should be set to 'rgmii-id', since the PCB does not add
the delays.

Ideally, you want to read from the IO ring if it is synthesised to do
the 2ns delays. Assuming it is enabled, you then mask the phy-mode
before connecting to the PHY, so avoiding double delays.

	Andrew

Re: [PATCH 3/4] arm64: dts: socfpga: agilex5: enable gmac2 on the Agilex5 dev kit

[Andrew Lunn]

> Currently the
> driver, drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c, and its
> bindings, Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml,
> allow all rgmii phy-modes.

There is nothing unusual about allowing all four RGMII modes. Somebody
might design a board with the 2ns delay via extra long clocks lines,
or some other form of delay lines. Such a board would need 'rgmii',
and they do exist, a board like this was added this cycle. There is
one rather odd board with a DT file which has extra long clock line
for TX, but not RX! That needs rgmii-rxid. The majority of boards
don't have any delays on the PCB, so need 'rgmii-id'.

	Andrew

Re: [PATCH 1/4] dt-bindings: net: altr,socfpga-stmmac: Add compatible string for Agilex5

[Rob Herring]

On Mon, Jul 14, 2025 at 08:25:25AM -0700, Matthew Gerlach wrote:
> Add compatible string for the Altera Agilex5 variant of the Synopsys DWC
> XGMAC IP version 2.10.
> 
> Signed-off-by: Matthew Gerlach <matthew.gerlach@altera.com>
> ---
>  .../devicetree/bindings/net/altr,socfpga-stmmac.yaml     | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml b/Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml
> index ec34daff2aa0..6d5c31c891de 100644
> --- a/Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml
> +++ b/Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml
> @@ -11,8 +11,8 @@ maintainers:
>  
>  description:
>    This binding describes the Altera SOCFPGA SoC implementation of the
> -  Synopsys DWMAC for the Cyclone5, Arria5, Stratix10, and Agilex7 families
> -  of chips.
> +  Synopsys DWMAC for the Cyclone5, Arria5, Stratix10, Agilex5 and Agilex7
> +  families of chips.
>    # TODO: Determine how to handle the Arria10 reset-name, stmmaceth-ocp, that
>    # does not validate against net/snps,dwmac.yaml.
>  
> @@ -23,6 +23,7 @@ select:
>          enum:
>            - altr,socfpga-stmmac
>            - altr,socfpga-stmmac-a10-s10
> +          - altr,socfpga-stmmac-agilex5
>  
>    required:
>      - compatible
> @@ -42,6 +43,10 @@ properties:
>            - const: altr,socfpga-stmmac-a10-s10
>            - const: snps,dwmac-3.74a
>            - const: snps,dwmac
> +      - items:
> +          - const: altr,socfpga-stmmac-agilex5

> +          - const: snps,dwxgmac-2.10
> +          - const: snps,dwxgmac

Is the distinction here useful? I doubt it, so I'd just drop the last 
one. Generally, we've moved away from any generic compatible for 
licensed IP like this because there's *always* some SoC specific 
difference. 

Rob

Re: [PATCH 1/4] dt-bindings: net: altr,socfpga-stmmac: Add compatible string for Agilex5

[Matthew Gerlach]

On 7/14/25 8:57 PM, Rob Herring wrote:
> On Mon, Jul 14, 2025 at 08:25:25AM -0700, Matthew Gerlach wrote:
> > Add compatible string for the Altera Agilex5 variant of the Synopsys DWC
> > XGMAC IP version 2.10.
> > 
> > Signed-off-by: Matthew Gerlach <matthew.gerlach@altera.com>
> > ---
> >  .../devicetree/bindings/net/altr,socfpga-stmmac.yaml     | 9 +++++++--
> >  1 file changed, 7 insertions(+), 2 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml b/Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml
> > index ec34daff2aa0..6d5c31c891de 100644
> > --- a/Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml
> > +++ b/Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml
> > @@ -11,8 +11,8 @@ maintainers:
> >  
> >  description:
> >    This binding describes the Altera SOCFPGA SoC implementation of the
> > -  Synopsys DWMAC for the Cyclone5, Arria5, Stratix10, and Agilex7 families
> > -  of chips.
> > +  Synopsys DWMAC for the Cyclone5, Arria5, Stratix10, Agilex5 and Agilex7
> > +  families of chips.
> >    # TODO: Determine how to handle the Arria10 reset-name, stmmaceth-ocp, that
> >    # does not validate against net/snps,dwmac.yaml.
> >  
> > @@ -23,6 +23,7 @@ select:
> >          enum:
> >            - altr,socfpga-stmmac
> >            - altr,socfpga-stmmac-a10-s10
> > +          - altr,socfpga-stmmac-agilex5
> >  
> >    required:
> >      - compatible
> > @@ -42,6 +43,10 @@ properties:
> >            - const: altr,socfpga-stmmac-a10-s10
> >            - const: snps,dwmac-3.74a
> >            - const: snps,dwmac
> > +      - items:
> > +          - const: altr,socfpga-stmmac-agilex5
>
> > +          - const: snps,dwxgmac-2.10
> > +          - const: snps,dwxgmac
>
> Is the distinction here useful? I doubt it, so I'd just drop the last
> one. Generally, we've moved away from any generic compatible for
> licensed IP like this because there's *always* some SoC specific
> difference.
>
> Rob

I will drop the '- const: snps, dwxgmac' in v2 and just list the following:

> +      - items:
> +          - const: altr,socfpga-stmmac-agilex5
> +          - const: snps,dwxgmac-2.10


Thanks for the feedback,
Matthew Gerlach

Re: [PATCH 3/4] arm64: dts: socfpga: agilex5: enable gmac2 on the Agilex5 dev kit

[Matthew Gerlach]

On 7/14/25 3:50 PM, Andrew Lunn wrote:
> On Mon, Jul 14, 2025 at 03:29:21PM -0700, Matthew Gerlach wrote:
> > 
> > 
> > On 7/14/25 11:52 AM, Andrew Lunn wrote:
> > > On Mon, Jul 14, 2025 at 11:09:33AM -0700, Matthew Gerlach wrote:
> > > > > > On 7/14/25 10:25 AM, Andrew Lunn wrote:
> > > > > > +&gmac2 {
> > > > > > +	status = "okay";
> > > > > > +	phy-mode = "rgmii";	/* Delays implemented by the IO ring of the Agilex5 SOCFPGA. */
> > > > > > > Please could you explain in more details what this means.
> > > > > > > The normal meaning for 'rgmii' is that the PCB implements the
> > > delay. I
> > > > > just want to fully understand what this IO ring is, and if it is part
> > > > > of the PCB.
> > > > > The IO ring is the logic in the Agilex5 that controls the pins on
> > > the chip.
> > > > It is this logic that sits between the MAC IP in the Agilex5 and the pins
> > > > connected to the PCB that is inserting the necessary delays. Technically the
> > > > PCB is not implementing the delays, but the "wires" between the MAC and the
> > > > external pins of the Agilex5 are implementing the delay. It seems to me that
> > > > "rgmii" is a more accurate description of the hardware than "rgmii-id" in
> > > > this case.
> > > 
> > > Is this delay hard coded, physically impossible to be disabled? A
> > > syntheses option? Can it be changed at run time? Is the IO ring under
> > > the control of a pinctrl driver? Can i use the standard 'skew-delay'
> > > DT property to control this delay?
>
> > The delay is not hard coded. It is a synthesis option that can be disabled.
>
> Is there a register you can read which tells you if it is
> enabled/disabled?

There are a collection of registers that could be examined to determine 
if delay has been inserted by IO ring.

>
> > The delay in the IO ring can be disabled, but implementing the delay in the
> > IO ring allows for RGMII phys that don't implement the delay.
>
> All RGMII PHYs which Linux support have the ability to do delays. And
> we recommend the PHY does the delay, just to keep all systems the
> same. There are a few exceptions, mostly because the MAC has hard
> coded delays which cannot be disabled, but i guess 90% of systems have
> the PHY doing the 2ns delays.
>
> So, phy-mode should be set to 'rgmii-id', since the PCB does not add
> the delays.

Understood. The PCB is not adding delays; so I'll change the phy-mode to 
be rgmii-id.

>
> Ideally, you want to read from the IO ring if it is synthesised to do
> the 2ns delays. Assuming it is enabled, you then mask the phy-mode
> before connecting to the PHY, so avoiding double delays.
>
> 	Andrew
>

Currently, the registers in question are considered secure and only 
accessible by
Arm Trusted Firmware (ATF). I will investigate implementing this delay 
detecting
logic in a future patchset.

Thanks for the feedback,

Matthew Gerlach