[PATCH 0/3] arm64: dts/net: stmmac: Add Agilex5 SoCDK TSN Config2 board support

[PATCH 0/3] arm64: dts/net: stmmac: Add Agilex5 SoCDK TSN Config2 board support

[muhammad.nazim.amirul.nazle.asmade]

From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>

The Intel SoCFPGA Agilex5 SoCDK TSN Config2 board uses a dual-port
Ethernet setup where gmac1 (TSN port) operates with different MAC-side
and PHY-side interface modes: GMII internally in the MAC, and RGMII
towards the PHY.

Russell King's commit de696c63c1dc ("net: stmmac: socfpga: convert to
use phy_interface") replaced mac_interface with phy_interface in
socfpga_get_plat_phymode(), correctly noting that no upstream DTS files
set the "mac-mode" property at the time. However, the Agilex5 SoCDK
TSN Config2 board requires mac-mode and phy-mode to differ, causing
ping failures when the MAC is configured with RGMII instead of GMII.

This series fixes the issue in three steps:

  Patch 1 (dt-bindings): Add the compatible string for the new board
  variant to Documentation/devicetree/bindings/arm/altera.yaml.

  Patch 2 (dts): Add the device tree source for the Agilex5 SoCDK
  TSN Config2 board, enabling gmac1 with mac-mode = "gmii" alongside
  the standard gmac2 port.

  Patch 3 (driver): Restore mac_interface support in dwmac-socfpga by
  reading the optional "mac-mode" DT property. When absent, it falls
  back to phy_interface, preserving existing behaviour for all other
  boards.

Note: Patches 1 and 2 target Dinh Nguyen's SoCFPGA tree
(git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git).
Patch 3 targets net-next.

Nazim Amirul (3):
  dt-bindings: arm: altera: Add Agilex5 SoCDK TSN Config2 board
  arm64: dts: socfpga: agilex5: Add SoCDK TSN Config2 board
  net: stmmac: dwmac-socfpga: Add mac-mode DT property support

 Documentation/devicetree/bindings/arm/altera.yaml            |   1 +
 arch/arm64/boot/dts/intel/Makefile                           |   9 +-
 arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_tsn_cfg2.dts | 133 ++++++++++++++++++
 drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c          |  23 ++-
 4 files changed, 162 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_tsn_cfg2.dts

-- 
2.43.7

[PATCH 1/3] dt-bindings: arm: altera: Add Agilex5 SoCDK TSN Config2 board board

[muhammad.nazim.amirul.nazle.asmade]

From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>

Add compatible string for the Intel SoCFPGA Agilex5 SoCDK TSN Config2
board variant, which uses a dual-port TSN configuration where gmac1
operates with different MAC-side (GMII) and PHY-side (RGMII) interface
modes.

Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
---
 Documentation/devicetree/bindings/arm/altera.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/altera.yaml b/Documentation/devicetree/bindings/arm/altera.yaml
index 3030cf46fe74..e431469a7175 100644
--- a/Documentation/devicetree/bindings/arm/altera.yaml
+++ b/Documentation/devicetree/bindings/arm/altera.yaml
@@ -114,6 +114,7 @@ properties:
               - intel,socfpga-agilex5-socdk-debug
               - intel,socfpga-agilex5-socdk-modular
               - intel,socfpga-agilex5-socdk-nand
+              - intel,socfpga-agilex5-socdk-tsn-cfg2
           - const: intel,socfpga-agilex5
 
       - description: Agilex72 boards
-- 
2.43.7

[PATCH 2/3] arm64: dts: socfpga: agilex5: Add SoCDK TSN Config2 board

[muhammad.nazim.amirul.nazle.asmade]

From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>

Add device tree for the Intel SoCFPGA Agilex5 SoCDK TSN Config2 board
variant. This configuration enables gmac1 as a TSN port alongside
the standard gmac2 Ethernet port.

The TSN port (gmac1) uses GMII internally in the MAC but connects to an
RGMII PHY. The mac-mode property is set to "gmii" to reflect the
MAC-side interface, while phy-mode is set to "rgmii" for the PHY-side
interface.

Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
---
 arch/arm64/boot/dts/intel/Makefile            |   3 +-
 .../intel/socfpga_agilex5_socdk_tsn_cfg2.dts  | 133 ++++++++++++++++++
 2 files changed, 135 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_tsn_cfg2.dts

diff --git a/arch/arm64/boot/dts/intel/Makefile b/arch/arm64/boot/dts/intel/Makefile
index 270c70fdf084..fc7ba2c6384b 100644
--- a/arch/arm64/boot/dts/intel/Makefile
+++ b/arch/arm64/boot/dts/intel/Makefile
@@ -4,10 +4,11 @@ dtb-$(CONFIG_ARCH_INTEL_SOCFPGA) += socfpga_agilex_n6000.dtb \
 				socfpga_agilex_socdk_emmc.dtb \
 				socfpga_agilex_socdk_nand.dtb \
 				socfpga_agilex3_socdk.dtb \
-				socfpga_agilex5_socdk.dtb \
+			socfpga_agilex5_socdk.dtb \
 				socfpga_agilex5_socdk_013b.dtb \
 				socfpga_agilex5_socdk_modular.dtb \
 				socfpga_agilex5_socdk_nand.dtb \
+				socfpga_agilex5_socdk_tsn_cfg2.dtb \
 				socfpga_agilex72_socdk.dtb \
 				socfpga_agilex7m_socdk.dtb \
 				socfpga_n5x_socdk.dtb
diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_tsn_cfg2.dts b/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_tsn_cfg2.dts
new file mode 100644
index 000000000000..f84f41a647ae
--- /dev/null
+++ b/arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_tsn_cfg2.dts
@@ -0,0 +1,133 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2026, Altera Corporation
+ */
+#include "socfpga_agilex5.dtsi"
+
+/ {
+	model = "SoCFPGA Agilex5 SoCDK TSN Config2";
+	compatible = "intel,socfpga-agilex5-socdk-tsn-cfg2", "intel,socfpga-agilex5";
+
+	aliases {
+		serial0 = &uart0;
+		ethernet1 = &gmac1;
+		ethernet2 = &gmac2;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		led-0 {
+			label = "hps_led0";
+			gpios = <&porta 11 GPIO_ACTIVE_HIGH>;
+		};
+
+	};
+
+	memory@80000000 {
+		device_type = "memory";
+		/* We expect the bootloader to fill in the reg */
+		reg = <0x0 0x80000000 0x0 0x0>;
+	};
+};
+
+&gpio0 {
+	status = "okay";
+};
+
+&gpio1 {
+	status = "okay";
+};
+
+/*
+ * gmac1 is the TSN port. The MAC operates in GMII mode internally
+ * while the PHY-side interface is RGMII, so mac-mode and phy-mode differ.
+ */
+&gmac1 {
+	status = "okay";
+	phy-mode = "rgmii"; /* TX/RX clock delays provided by Agilex5 I/O hardware */
+	mac-mode = "gmii";
+	phy-handle = <&emac1_phy0>;
+	max-frame-size = <9000>;
+
+	mdio0 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "snps,dwmac-mdio";
+
+		emac1_phy0: ethernet-phy@0 {
+			reg = <0>;
+		};
+	};
+};
+
+&gmac2 {
+	status = "okay";
+	phy-mode = "rgmii"; /* TX/RX clock delays provided by Agilex5 I/O hardware */
+	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>;
+		};
+	};
+};
+
+&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>;
+			};
+		};
+	};
+};
+
+&uart0 {
+	status = "okay";
+};
+
+&usb0 {
+	status = "okay";
+	disable-over-current;
+};
+
+&watchdog0 {
+	status = "okay";
+};
-- 
2.43.7

[PATCH 3/3] net: stmmac: dwmac-socfpga: Add mac-mode DT property support

[muhammad.nazim.amirul.nazle.asmade]

From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>

Russell King's commit de696c63c1dc ("net: stmmac: socfpga: convert to
use phy_interface") replaced mac_interface with phy_interface in
socfpga_get_plat_phymode(), noting that no upstream DTS files set the
"mac-mode" property, making the two values identical.

The Agilex5 SoCDK TSN Config2 board is an exception: its gmac1 TSN
port uses GMII internally in the MAC while the PHY-side interface is
RGMII, so mac-mode and phy-mode differ. Without restoring mac_interface
support, the MAC is configured with RGMII instead of GMII, causing
connectivity failures on this board.

Add socfpga_of_get_mac_mode() to read the optional "mac-mode" DT
property and store it in a new mac_interface field. When the property
is absent, mac_interface falls back to phy_interface, preserving
the existing behaviour for all other boards.

Fixes: de696c63c1dc ("net: stmmac: socfpga: convert to use phy_interface")
Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
---
 .../ethernet/stmicro/stmmac/dwmac-socfpga.c   | 23 ++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
index 1d7f0a57d288..6a6837c4a414 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -69,12 +69,30 @@ struct socfpga_dwmac {
 	void __iomem *tse_pcs_base;
 	void __iomem *sgmii_adapter_base;
 	bool f2h_ptp_ref_clk;
+	phy_interface_t mac_interface;
 	const struct socfpga_dwmac_ops *ops;
 };
 
+static int socfpga_of_get_mac_mode(struct device_node *np)
+{
+	const char *pm;
+	int err, i;
+
+	err = of_property_read_string(np, "mac-mode", &pm);
+	if (err < 0)
+		return err;
+
+	for (i = 0; i < PHY_INTERFACE_MODE_MAX; i++) {
+		if (!strcasecmp(pm, phy_modes(i)))
+			return i;
+	}
+
+	return -ENODEV;
+}
+
 static phy_interface_t socfpga_get_plat_phymode(struct socfpga_dwmac *dwmac)
 {
-	return dwmac->plat_dat->phy_interface;
+	return dwmac->mac_interface;
 }
 
 static void socfpga_sgmii_config(struct socfpga_dwmac *dwmac, bool enable)
@@ -650,6 +668,9 @@ static int socfpga_dwmac_probe(struct platform_device *pdev)
 	plat_dat->pcs_exit = socfpga_dwmac_pcs_exit;
 	plat_dat->select_pcs = socfpga_dwmac_select_pcs;
 
+	ret = socfpga_of_get_mac_mode(pdev->dev.of_node);
+	dwmac->mac_interface = ret < 0 ? plat_dat->phy_interface : ret;
+
 	ops->setup_plat_dat(dwmac);
 
 	return devm_stmmac_pltfr_probe(pdev, plat_dat, &stmmac_res);
-- 
2.43.7

Re: [PATCH 0/3] arm64: dts/net: stmmac: Add Agilex5 SoCDK TSN Config2 board support

[Maxime Chevallier]

Hi,

On 6/30/26 15:31, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
> 
> The Intel SoCFPGA Agilex5 SoCDK TSN Config2 board uses a dual-port
> Ethernet setup where gmac1 (TSN port) operates with different MAC-side
> and PHY-side interface modes: GMII internally in the MAC, and RGMII
> towards the PHY.

There's the same behaviour on Gen5, e.g. CycloneV where we have the
"EMAC splitter". Based on wether or not we have that splitter in DT,
we override the INTF_SEL bits to set GMII as the MAC output, the splitter
converting that to RGMII/SGMII.

Is there something similar on this AgileX5 version by any chance, for
which we could reuse the logic ?

I know that on CycloneV you also need to adjust that GMII -> RGMII/SGMII
splitter whenever the speed changes, is that different on agileX5 ? have
you tested 10/100Mbps ?

Thanks,

Maxime

Re: [PATCH 2/3] arm64: dts: socfpga: agilex5: Add SoCDK TSN Config2 board

[Andrew Lunn]

> + * gmac1 is the TSN port. The MAC operates in GMII mode internally
> + * while the PHY-side interface is RGMII, so mac-mode and phy-mode differ.
> + */
> +&gmac1 {
> +	status = "okay";
> +	phy-mode = "rgmii"; /* TX/RX clock delays provided by Agilex5 I/O hardware */

Could you provide more details about this. I want to understand the
big picture.

Normally we talk about the PCB providing the delays. This sounds like
it is the FPGA? So i need convincing this is correct.

https://elixir.bootlin.com/linux/v6.15/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L287

	Andrew

Re: [PATCH 3/3] net: stmmac: dwmac-socfpga: Add mac-mode DT property support

[Andrew Lunn]

On Tue, Jun 30, 2026 at 06:31:08AM -0700, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
> 
> Russell King's commit de696c63c1dc ("net: stmmac: socfpga: convert to
> use phy_interface") replaced mac_interface with phy_interface in
> socfpga_get_plat_phymode(), noting that no upstream DTS files set the
> "mac-mode" property, making the two values identical.
> 
> The Agilex5 SoCDK TSN Config2 board is an exception: its gmac1 TSN
> port uses GMII internally in the MAC while the PHY-side interface is
> RGMII, so mac-mode and phy-mode differ.

Maybe you need to represent the hardware block which magically
converts GMII to RGMII in DT?

	 Andrew

Re: [PATCH 3/3] net: stmmac: dwmac-socfpga: Add mac-mode DT property support

[Maxime Chevallier]

On 6/30/26 16:02, Andrew Lunn wrote:
> On Tue, Jun 30, 2026 at 06:31:08AM -0700, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
>> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
>>
>> Russell King's commit de696c63c1dc ("net: stmmac: socfpga: convert to
>> use phy_interface") replaced mac_interface with phy_interface in
>> socfpga_get_plat_phymode(), noting that no upstream DTS files set the
>> "mac-mode" property, making the two values identical.
>>
>> The Agilex5 SoCDK TSN Config2 board is an exception: its gmac1 TSN
>> port uses GMII internally in the MAC while the PHY-side interface is
>> RGMII, so mac-mode and phy-mode differ.
> 
> Maybe you need to represent the hardware block which magically
> converts GMII to RGMII in DT?

Yeah that's what we have on CycloneV, and we force the INTF_SEL to GMII if that
HW block is present. I wonder if there's the same on agileX5 ?

> 
> 	 Andrew

Re: [PATCH 2/3] arm64: dts: socfpga: agilex5: Add SoCDK TSN Config2 board

[Nazle Asmade, Muhammad Nazim Amirul]

On 30/6/2026 9:58 pm, Andrew Lunn wrote:
>> + * gmac1 is the TSN port. The MAC operates in GMII mode internally
>> + * while the PHY-side interface is RGMII, so mac-mode and phy-mode differ.
>> + */
>> +&gmac1 {
>> +	status = "okay";
>> +	phy-mode = "rgmii"; /* TX/RX clock delays provided by Agilex5 I/O hardware */
> Could you provide more details about this. I want to understand the
> big picture.
> 
> Normally we talk about the PCB providing the delays. This sounds like
> it is the FPGA? So i need convincing this is correct.
Hi Andrew,

Thanks for your quick review and yes, it is the FPGA — specifically a 
soft IP block in the FPGA fabric that implements the RGMII clock delays 
and is configured before Linux boots via the FPGA bitstream. The driver 
must not add additional delays on top.

BR,
Nazim

Re: [PATCH 3/3] net: stmmac: dwmac-socfpga: Add mac-mode DT property support

[Nazle Asmade, Muhammad Nazim Amirul]

On 30/6/2026 10:04 pm, Maxime Chevallier wrote:
> On 6/30/26 16:02, Andrew Lunn wrote:
>> On Tue, Jun 30, 2026 at 06:31:08AM -0700, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
>>> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
>>>
>>> Russell King's commit de696c63c1dc ("net: stmmac: socfpga: convert to
>>> use phy_interface") replaced mac_interface with phy_interface in
>>> socfpga_get_plat_phymode(), noting that no upstream DTS files set the
>>> "mac-mode" property, making the two values identical.
>>>
>>> The Agilex5 SoCDK TSN Config2 board is an exception: its gmac1 TSN
>>> port uses GMII internally in the MAC while the PHY-side interface is
>>> RGMII, so mac-mode and phy-mode differ.
>>
>> Maybe you need to represent the hardware block which magically
>> converts GMII to RGMII in DT?
> 
> Yeah that's what we have on CycloneV, and we force the INTF_SEL to GMII if that
> HW block is present. I wonder if there's the same on agileX5 ?

Hi Maxime, Andrew

Yes, Agilex5 has the same concept. The GMII-to-RGMII converter is a 
Quartus soft IP instantiated in the FPGA fabric — equivalent to the 
CycloneV EMAC splitter. The XGMAC outputs GMII signals to the FPGA 
fabric, the soft IP converts them to RGMII, and the RGMII signals then 
go through the FPGA HVIO pins to the external Marvell 88E1512 PHY.

BR,
Nazim>
>>
>> 	 Andrew
> 

Re: [PATCH 2/3] arm64: dts: socfpga: agilex5: Add SoCDK TSN Config2 board

[Andrew Lunn]

On Tue, Jun 30, 2026 at 02:39:50PM +0000, Nazle Asmade, Muhammad Nazim Amirul wrote:
> On 30/6/2026 9:58 pm, Andrew Lunn wrote:
> >> + * gmac1 is the TSN port. The MAC operates in GMII mode internally
> >> + * while the PHY-side interface is RGMII, so mac-mode and phy-mode differ.
> >> + */
> >> +&gmac1 {
> >> +	status = "okay";
> >> +	phy-mode = "rgmii"; /* TX/RX clock delays provided by Agilex5 I/O hardware */
> > Could you provide more details about this. I want to understand the
> > big picture.
> > 
> > Normally we talk about the PCB providing the delays. This sounds like
> > it is the FPGA? So i need convincing this is correct.
> Hi Andrew,
> 
> Thanks for your quick review and yes, it is the FPGA — specifically a 
> soft IP block in the FPGA fabric that implements the RGMII clock delays 
> and is configured before Linux boots via the FPGA bitstream. The driver 
> must not add additional delays on top.

So it depends on how the converter block is described, but ....

From a big picture, MAC and PHY pair, it is the MAC which
implements the delays.

https://elixir.bootlin.com/linux/v6.15/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L346

# There are a small number of cases where the MAC has hard coded
# delays which cannot be disabled. The 'phy-mode' only describes the
# PCB.  The inability to disable the delays in the MAC does not change
# the meaning of 'phy-mode'. It does however mean that a 'phy-mode' of
# 'rgmii' is now invalid, it cannot be supported, since both the PCB
# and the MAC and PHY adding delays cannot result in a functional
# link. Thus the MAC should report a fatal error for any modes which
# cannot be supported. When the MAC implements the delay, it must
# ensure that the PHY does not also implement the same delay. So it
# must modify the phy-mode it passes to the PHY, removing the delay it
# has added. Failure to remove the delay will result in a
# non-functioning link.

    Andrew

---
pw-bot: cr

Re: [PATCH 3/3] net: stmmac: dwmac-socfpga: Add mac-mode DT property support

[Maxime Chevallier]

On 6/30/26 17:13, Nazle Asmade, Muhammad Nazim Amirul wrote:

> Yes, Agilex5 has the same concept. The GMII-to-RGMII converter is a 
> Quartus soft IP instantiated in the FPGA fabric — equivalent to the 
> CycloneV EMAC splitter. The XGMAC outputs GMII signals to the FPGA 
> fabric, the soft IP converts them to RGMII, and the RGMII signals then 
> go through the FPGA HVIO pins to the external Marvell 88E1512 PHY.

Does this converter need any special config, and does it expose any
control registers ? or is it fully autonomous ?

If it's fully autonomous, can you detect its presence through some
capability registers or something like that ?


Maxime

Re: [PATCH 3/3] net: stmmac: dwmac-socfpga: Add mac-mode DT property support

[Nazle Asmade, Muhammad Nazim Amirul]

On 30/6/2026 11:42 pm, Maxime Chevallier wrote:
> 
> 
> On 6/30/26 17:13, Nazle Asmade, Muhammad Nazim Amirul wrote:
> 
>> Yes, Agilex5 has the same concept. The GMII-to-RGMII converter is a
>> Quartus soft IP instantiated in the FPGA fabric — equivalent to the
>> CycloneV EMAC splitter. The XGMAC outputs GMII signals to the FPGA
>> fabric, the soft IP converts them to RGMII, and the RGMII signals then
>> go through the FPGA HVIO pins to the external Marvell 88E1512 PHY.
> 
> Does this converter need any special config, and does it expose any
> control registers ? or is it fully autonomous ?
> 
> If it's fully autonomous, can you detect its presence through some
> capability registers or something like that ?
> 
> 
> Maxime
> 
Hi Maxime,

Per my knowledge, the converter is fully autonomous with no control 
registers and no software configuration required.

Speed switching is handled entirely in hardware — the XGMAC's mac_speed 
output signals are wired directly in the FPGA fabric to the converter's 
speed input. No driver intervention is needed on speed changes.

There are no capability registers and no way to detect its presence in 
hardware. It is a property of the FPGA design, not the HPS silicon.

BR,
Nazim Amirul

Re: [PATCH 2/3] arm64: dts: socfpga: agilex5: Add SoCDK TSN Config2 board

[Nazle Asmade, Muhammad Nazim Amirul]

On 30/6/2026 11:25 pm, Andrew Lunn wrote:
> On Tue, Jun 30, 2026 at 02:39:50PM +0000, Nazle Asmade, Muhammad Nazim Amirul wrote:
>> On 30/6/2026 9:58 pm, Andrew Lunn wrote:
>>>> + * gmac1 is the TSN port. The MAC operates in GMII mode internally
>>>> + * while the PHY-side interface is RGMII, so mac-mode and phy-mode differ.
>>>> + */
>>>> +&gmac1 {
>>>> +  status = "okay";
>>>> +  phy-mode = "rgmii"; /* TX/RX clock delays provided by Agilex5 I/O hardware */
>>> Could you provide more details about this. I want to understand the
>>> big picture.
>>>
>>> Normally we talk about the PCB providing the delays. This sounds like
>>> it is the FPGA? So i need convincing this is correct.
>> Hi Andrew,
>>
>> Thanks for your quick review and yes, it is the FPGA — specifically a
>> soft IP block in the FPGA fabric that implements the RGMII clock delays
>> and is configured before Linux boots via the FPGA bitstream. The driver
>> must not add additional delays on top.
>
> So it depends on how the converter block is described, but ....
>
>  From a big picture, MAC and PHY pair, it is the MAC which
> implements the delays.
>
> https://elixir.bootlin.com/linux/v6.15/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L346
>
> # There are a small number of cases where the MAC has hard coded
> # delays which cannot be disabled. The 'phy-mode' only describes the
> # PCB.  The inability to disable the delays in the MAC does not change
> # the meaning of 'phy-mode'. It does however mean that a 'phy-mode' of
> # 'rgmii' is now invalid, it cannot be supported, since both the PCB
> # and the MAC and PHY adding delays cannot result in a functional
> # link. Thus the MAC should report a fatal error for any modes which
> # cannot be supported. When the MAC implements the delay, it must
> # ensure that the PHY does not also implement the same delay. So it
> # must modify the phy-mode it passes to the PHY, removing the delay it
> # has added. Failure to remove the delay will result in a
> # non-functioning link.
>
>      Andrew
>
> ---
> pw-bot: cr
Hi Andrew,

The delays are provided by the FPGA GMII-to-RGMII converter soft IP,
which is hardcoded in the FPGA bitstream and cannot be disabled or
modified from the driver side.

Using phy-mode = "rgmii" is intentional here — it prevents the PHY from
adding its own internal delays on top, since the FPGA converter already
provides the full required delay. This is consistent with how all other
Agilex5 SoCDK board variants are described, as seen in commit
c5637e5ceb4b ("arm64: dts: socfpga: agilex5: Fix phy-mode to rgmii as HW
provides clock delay") already in Dinh Nguyen's tree, which applies the
same rationale across all Agilex5 boards.

BR,
Nazim Amirul

Re: [PATCH 0/3] arm64: dts/net: stmmac: Add Agilex5 SoCDK TSN Config2 board support

[Nazle Asmade, Muhammad Nazim Amirul]

On 30/6/2026 9:53 pm, Maxime Chevallier wrote:
> Hi,
> 
> On 6/30/26 15:31, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
>> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
>>
>> The Intel SoCFPGA Agilex5 SoCDK TSN Config2 board uses a dual-port
>> Ethernet setup where gmac1 (TSN port) operates with different MAC-side
>> and PHY-side interface modes: GMII internally in the MAC, and RGMII
>> towards the PHY.
> 
> There's the same behaviour on Gen5, e.g. CycloneV where we have the
> "EMAC splitter". Based on wether or not we have that splitter in DT,
> we override the INTF_SEL bits to set GMII as the MAC output, the splitter
> converting that to RGMII/SGMII.
> 
> Is there something similar on this AgileX5 version by any chance, for
> which we could reuse the logic ?
> 
> I know that on CycloneV you also need to adjust that GMII -> RGMII/SGMII
> splitter whenever the speed changes, is that different on agileX5 ? have
> you tested 10/100Mbps ?
> 
> Thanks,
> 
> Maxime
Hi Maxime,

Yes, we have tested all three speeds.

10Mbps: Link Up - 10Mbps/Full, throughput ~9.35 Mbits/sec 100Mbps: Link 
Up - 100Mbps/Full, throughput ~94 Mbits/sec 1000Mbps: Link Up - 
1Gbps/Full, throughput ~930 Mbits/sec

BR,
Nazim

Re: [PATCH 3/3] net: stmmac: dwmac-socfpga: Add mac-mode DT property support

[Maxime Chevallier]

Hi,

On 6/30/26 15:31, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
> 
> Russell King's commit de696c63c1dc ("net: stmmac: socfpga: convert to
> use phy_interface") replaced mac_interface with phy_interface in
> socfpga_get_plat_phymode(), noting that no upstream DTS files set the
> "mac-mode" property, making the two values identical.
> 
> The Agilex5 SoCDK TSN Config2 board is an exception: its gmac1 TSN
> port uses GMII internally in the MAC while the PHY-side interface is
> RGMII, so mac-mode and phy-mode differ. Without restoring mac_interface
> support, the MAC is configured with RGMII instead of GMII, causing
> connectivity failures on this board.
> 
> Add socfpga_of_get_mac_mode() to read the optional "mac-mode" DT
> property and store it in a new mac_interface field. When the property
> is absent, mac_interface falls back to phy_interface, preserving
> the existing behaviour for all other boards.

After our discussions, indeed mac-mode seems to be the way to go, however
I have some remarks on how it's handled right now.

> 
> Fixes: de696c63c1dc ("net: stmmac: socfpga: convert to use phy_interface")
> Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
> ---
>  .../ethernet/stmicro/stmmac/dwmac-socfpga.c   | 23 ++++++++++++++++++-
>  1 file changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
> index 1d7f0a57d288..6a6837c4a414 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
> @@ -69,12 +69,30 @@ struct socfpga_dwmac {
>  	void __iomem *tse_pcs_base;
>  	void __iomem *sgmii_adapter_base;
>  	bool f2h_ptp_ref_clk;
> +	phy_interface_t mac_interface;
>  	const struct socfpga_dwmac_ops *ops;
>  };
>  
> +static int socfpga_of_get_mac_mode(struct device_node *np)
> +{
> +	const char *pm;
> +	int err, i;
> +
> +	err = of_property_read_string(np, "mac-mode", &pm);
> +	if (err < 0)
> +		return err;
> +
> +	for (i = 0; i < PHY_INTERFACE_MODE_MAX; i++) {
> +		if (!strcasecmp(pm, phy_modes(i)))
> +			return i;
> +	}
> +
> +	return -ENODEV;
> +}
> +
>  static phy_interface_t socfpga_get_plat_phymode(struct socfpga_dwmac *dwmac)
>  {
> -	return dwmac->plat_dat->phy_interface;
> +	return dwmac->mac_interface;
>  }

Taking a look at the logic in socfpga_gen{5|10}_set_phy_mode(), we have :

  phy_interface_t phymode = socfpga_get_plat_phymode(dwmac);
  u32 val;

  socfpga_set_phy_mode_common(phymode, &val)

  if (dwmac->splitter_base)
	  val = SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_GMII_MII;

[...]

  if (phymode == PHY_INTERFACE_MODE_SGMII)
	  socfpga_sgmii_config(dwmac, true);



With this new patch, we now have 2 different ways of handling this
converter block (splitter presence, and mac-mode presence in DT)

Can you unify this a bit ?

One thing could be adding a helper to get the macmode such as
socfpga_get_plat_macmode()

I think we should move the splitter handling before calling 
socfpga_get_plat_macmode() :

 if (dwmac->splitter_base)
   	dwmav->mac_interface = PHY_INTERFACE_MODE_GMII

We'd get the intf_sel value based on the macmode, and also calls to
helpers such as socfpga_sgmii_config(phymode, xxx) need the actual
phymode as a parameter, not the macmode.

Thanks :)

Maxime

Re: [PATCH 2/3] arm64: dts: socfpga: agilex5: Add SoCDK TSN Config2 board

[Andrew Lunn]

> > # There are a small number of cases where the MAC has hard coded
> > # delays which cannot be disabled. The 'phy-mode' only describes the
> > # PCB.  The inability to disable the delays in the MAC does not change
> > # the meaning of 'phy-mode'. It does however mean that a 'phy-mode' of
> > # 'rgmii' is now invalid, it cannot be supported, since both the PCB
> > # and the MAC and PHY adding delays cannot result in a functional
> > # link. Thus the MAC should report a fatal error for any modes which
> > # cannot be supported. When the MAC implements the delay, it must
> > # ensure that the PHY does not also implement the same delay. So it
> > # must modify the phy-mode it passes to the PHY, removing the delay it
> > # has added. Failure to remove the delay will result in a
> > # non-functioning link.
> >
> >      Andrew
> >
> > ---
> > pw-bot: cr
> Hi Andrew,
> 
> The delays are provided by the FPGA GMII-to-RGMII converter soft IP,
> which is hardcoded in the FPGA bitstream and cannot be disabled or
> modified from the driver side.
> 
> Using phy-mode = "rgmii" is intentional here — it prevents the PHY from
> adding its own internal delays on top, since the FPGA converter already
> provides the full required delay. This is consistent with how all other
> Agilex5 SoCDK board variants are described, as seen in commit
> c5637e5ceb4b ("arm64: dts: socfpga: agilex5: Fix phy-mode to rgmii as HW
> provides clock delay") already in Dinh Nguyen's tree, which applies the
> same rationale across all Agilex5 boards.

I've become more insistent that designs get this correct. So i don't
care too much about past systems. Many vendors are having to fix up
their drivers and DT in order to make new boards consistent.

You can look at your system as the FPGA being the MAC, and the PHY is
the PHY. The PCB is not providing the delay, the MAC is. This exactly
fits the description above.

     Andrew

Re: [PATCH 3/3] net: stmmac: dwmac-socfpga: Add mac-mode DT property support

[Andrew Lunn]

On Tue, Jun 30, 2026 at 06:31:08AM -0700, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
> 
> Russell King's commit de696c63c1dc ("net: stmmac: socfpga: convert to
> use phy_interface") replaced mac_interface with phy_interface in
> socfpga_get_plat_phymode(), noting that no upstream DTS files set the
> "mac-mode" property, making the two values identical.
> 
> The Agilex5 SoCDK TSN Config2 board is an exception: its gmac1 TSN
> port uses GMII internally in the MAC while the PHY-side interface is
> RGMII, so mac-mode and phy-mode differ. Without restoring mac_interface
> support, the MAC is configured with RGMII instead of GMII, causing
> connectivity failures on this board.
> 
> Add socfpga_of_get_mac_mode() to read the optional "mac-mode" DT
> property and store it in a new mac_interface field. When the property
> is absent, mac_interface falls back to phy_interface, preserving
> the existing behaviour for all other boards.

I don't actually see a need for mac-mode. From what you are saying,
there is no choice. The MAC is hard wired to the converter block. So
you can just look at the compatible. You are going to need to use the
compatible anyway, to mask the phy-mode to handle the "MAC" doing the
RGMII delays.

      Andrew