[PATCH net-next 0/2] net: stmmac: dwmac-socfpga: Add Agilex5 TSN GMAC support

[PATCH net-next 0/2] net: stmmac: dwmac-socfpga: Add Agilex5 TSN GMAC support

[muhammad.nazim.amirul.nazle.asmade]

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

This series adds support for the gmac1 TSN port on the Intel SoCFPGA
Agilex5 SoCDK TSN Config2 board.

The TSN port (gmac1) connects to its PHY through a GMII-to-RGMII converter
implemented as FPGA soft IP. This converter provides the RGMII TX/RX clock
delays, requiring the MAC interface selector to be configured for GMII while
the PHY-facing interface is configured as RGMII without delay duplication.

Patch 1 documents the altr,socfpga-stmmac-agilex5-tsn compatible. Patch 2
adds dedicated match .data ops for the required interface setup.

These two patches were previously posted as patches 3 and 4 of the
"Add Agilex5 SoCDK TSN Config2 board support" series (up to v6). Per
Jakub Kicinski's request, they are reposted here as a separate series
for net-next. The board-level binding and DTS patches will be sent
separately to the SoCFPGA tree.

Changes since the v6 board series:
  - Split out the networking patches, rebased onto latest net-next.
  - Add Reviewed-by from Maxime Chevallier on patch 2.

History from the board series:

v6:
  - Put altr,socfpga-stmmac-agilex5-tsn in the same compatible enum as
    altr,socfpga-stmmac-agilex5 in the net binding, per Krzysztof Kozlowski.

v5:
  - Replace of_device_is_compatible() probe check with dedicated
    socfpga_agilex5_tsn_gmac_ops via match .data, per Krzysztof Kozlowski
    and Dinh Nguyen.
  - Drop altr,socfpga-stmmac-agilex5 fallback from the TSN compatible list
    and rewrite the net binding commit message to explain the hardware
    difference, per Krzysztof Kozlowski.

v4:
  - Add Reviewed-by from Andrew Lunn on the driver patch.

v2:
  - Replace mac-mode DT property with compatible string-based detection per
    Andrew Lunn's feedback.
  - Use phy-mode = "rgmii-id" to correctly reflect MAC-side delay handling.
  - Rename compatible string to altr,socfpga-stmmac-agilex5-tsn for
    consistency with existing altr,socfpga-stmmac-* compatibles.
  - Add DT binding documentation for new net compatible string (new patch).

Nazim Amirul (2):
  dt-bindings: net: altr,socfpga-stmmac: Add
    altr,socfpga-stmmac-agilex5-tsn compatible
  net: stmmac: dwmac-socfpga: Add support for Agilex5 TSN GMAC with FPGA
    converter

 .../bindings/net/altr,socfpga-stmmac.yaml     |  5 +++-
 .../ethernet/stmicro/stmmac/dwmac-socfpga.c   | 23 ++++++++++++++++++-
 2 files changed, 26 insertions(+), 2 deletions(-)

-- 
2.43.7

[PATCH net-next 1/2] dt-bindings: net: altr,socfpga-stmmac: Add altr,socfpga-stmmac-agilex5-tsn compatible

[muhammad.nazim.amirul.nazle.asmade]

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

The Agilex5 SoCDK TSN Config2 gmac1 path includes an FPGA soft-IP
GMII-to-RGMII converter between the DWXGMAC and the PHY. The converter
provides the RGMII TX/RX delays and presents GMII toward the MAC, unlike
a plain altr,socfpga-stmmac-agilex5 port with no such converter.

Add altr,socfpga-stmmac-agilex5-tsn for that integration in the same
compatible items entry as altr,socfpga-stmmac-agilex5 (shared
snps,dwxgmac-2.10). Do not use altr,socfpga-stmmac-agilex5 as a DT
fallback for the TSN port; the converter presents GMII to the MAC and
supplies the RGMII delays, unlike a plain Agilex5 GMAC port.

Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
---
Previously patch 3 of the v6 board series; split out for net-next.
Rebase only.

v6: Put altr,socfpga-stmmac-agilex5-tsn in the same enum as
    altr,socfpga-stmmac-agilex5, per Krzysztof Kozlowski.
v5: Drop altr,socfpga-stmmac-agilex5 fallback and rewrite commit message
    to explain hardware incompatibility, per Krzysztof Kozlowski.

 .../devicetree/bindings/net/altr,socfpga-stmmac.yaml         | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml b/Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml
index d8f90d36d246..ca768937d890 100644
--- a/Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml
+++ b/Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml
@@ -22,6 +22,7 @@ select:
           - altr,socfpga-stmmac
           - altr,socfpga-stmmac-a10-s10
           - altr,socfpga-stmmac-agilex5
+          - altr,socfpga-stmmac-agilex5-tsn
 
   required:
     - compatible
@@ -42,7 +43,9 @@ properties:
           - const: snps,dwmac-3.74a
           - const: snps,dwmac
       - items:
-          - const: altr,socfpga-stmmac-agilex5
+          - enum:
+              - altr,socfpga-stmmac-agilex5
+              - altr,socfpga-stmmac-agilex5-tsn
           - const: snps,dwxgmac-2.10
 
   clocks:
-- 
2.43.7

[PATCH net-next 2/2] net: stmmac: dwmac-socfpga: Add support for Agilex5 TSN GMAC with FPGA converter

[muhammad.nazim.amirul.nazle.asmade]

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

The Agilex5 SoCDK TSN Config2 board uses a GMII-to-RGMII converter
implemented as FPGA soft IP between gmac1 and its PHY. This converter
provides the RGMII TX/RX clock delays, so the MAC interface selector
must be configured for GMII while the PHY is configured without delays.

Add the "altr,socfpga-stmmac-agilex5-tsn" compatible with dedicated
match .data ops that extend the standard Agilex5 setup: force GMII for
the MAC interface selector and strip delay bits from phy_interface so
the PHY is not configured to add delays already provided by the FPGA
converter.

Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
Previously patch 4 of the v6 board series; split out for net-next.
Add Reviewed-by from Maxime Chevallier.

v6: No changes from v5.
v5: Replace of_device_is_compatible() probe check with dedicated
    socfpga_agilex5_tsn_gmac_ops via match .data, per Krzysztof
    Kozlowski and Dinh Nguyen.
v4: Add Reviewed-by from Andrew Lunn.

 .../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..0632105b420f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -69,12 +69,13 @@ 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 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 +651,8 @@ 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;
 
+	dwmac->mac_interface = plat_dat->phy_interface;
+
 	ops->setup_plat_dat(dwmac);
 
 	return devm_stmmac_pltfr_probe(pdev, plat_dat, &stmmac_res);
@@ -670,10 +673,28 @@ static const struct socfpga_dwmac_ops socfpga_agilex5_ops = {
 	.setup_plat_dat = socfpga_agilex5_setup_plat_dat,
 };
 
+static void socfpga_agilex5_tsn_gmac_setup_plat_dat(struct socfpga_dwmac *dwmac)
+{
+	struct plat_stmmacenet_data *plat_dat = dwmac->plat_dat;
+
+	socfpga_agilex5_setup_plat_dat(dwmac);
+
+	/* FPGA converter supplies RGMII delays; MAC uses GMII, PHY gets plain RGMII */
+	dwmac->mac_interface = PHY_INTERFACE_MODE_GMII;
+	if (phy_interface_mode_is_rgmii(plat_dat->phy_interface))
+		plat_dat->phy_interface = PHY_INTERFACE_MODE_RGMII;
+}
+
+static const struct socfpga_dwmac_ops socfpga_agilex5_tsn_gmac_ops = {
+	.set_phy_mode = socfpga_gen10_set_phy_mode,
+	.setup_plat_dat = socfpga_agilex5_tsn_gmac_setup_plat_dat,
+};
+
 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_agilex5_ops },
+	{ .compatible = "altr,socfpga-stmmac-agilex5-tsn", .data = &socfpga_agilex5_tsn_gmac_ops },
 	{ }
 };
 MODULE_DEVICE_TABLE(of, socfpga_dwmac_match);
-- 
2.43.7

Re: [PATCH net-next 1/2] dt-bindings: net: altr,socfpga-stmmac: Add altr,socfpga-stmmac-agilex5-tsn compatible

[Krzysztof Kozlowski]

On 23/09/2026 04:18, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
> 
> The Agilex5 SoCDK TSN Config2 gmac1 path includes an FPGA soft-IP
> GMII-to-RGMII converter between the DWXGMAC and the PHY. The converter
> provides the RGMII TX/RX delays and presents GMII toward the MAC, unlike
> a plain altr,socfpga-stmmac-agilex5 port with no such converter.
> 
> Add altr,socfpga-stmmac-agilex5-tsn for that integration in the same
> compatible items entry as altr,socfpga-stmmac-agilex5 (shared
> snps,dwxgmac-2.10). Do not use altr,socfpga-stmmac-agilex5 as a DT
> fallback for the TSN port; the converter presents GMII to the MAC and
> supplies the RGMII delays, unlike a plain Agilex5 GMAC port.
> 
> Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
> ---
> Previously patch 3 of the v6 board series; split out for net-next.
> Rebase only.
> 


Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof

Re: [PATCH net-next 1/2] dt-bindings: net: altr,socfpga-stmmac: Add altr,socfpga-stmmac-agilex5-tsn compatible

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 2 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 1 · Low: 1

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] The binding patch makes the new compatible "altr,socfpga-
  stmmac-agilex5-tsn" a peer of "altr,socfpga-stmmac-agilex5" in the…
- [Low] At this commit, socfpga_dwmac_match in
  drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c has no entry for…

--

dt-bindings: net: altr,socfpga-stmmac: Add altr,socfpga-stmmac-agilex5-tsn compatible

This adds the altr,socfpga-stmmac-agilex5-tsn compatible for the Agilex5
gmac1 port, which has an FPGA GMII-to-RGMII converter in front of the PHY.
The new string goes in the same enum as altr,socfpga-stmmac-agilex5, with
snps,dwxgmac-2.10 as the fallback. Plain agilex5 is intentionally not used
as a fallback.

> diff --git a/Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml b/Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml
> index d8f90d36d2469..ca768937d8905 100644
> --- a/Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml
> +++ b/Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml

[ ... ]

> @@ -42,7 +43,9 @@ properties:
>            - const: snps,dwmac-3.74a
>            - const: snps,dwmac
>        - items:
> -          - const: altr,socfpga-stmmac-agilex5
> +          - enum:
> +              - altr,socfpga-stmmac-agilex5
> +              - altr,socfpga-stmmac-agilex5-tsn
>            - const: snps,dwxgmac-2.10

[Severity: Medium]
Should the allOf conditional further down in this file also cover the new
compatible? It still matches only the plain agilex5 string:

  - if:
      properties:
        compatible:
          contains:
            const: altr,socfpga-stmmac-agilex5
    then:
      properties:
        interrupts:
          minItems: 17

        interrupt-names:
          minItems: 17

        dma-coherent: true
    else:
      properties:
        interrupts:
          maxItems: 1

        interrupt-names:
          maxItems: 1

        dma-coherent: false

The TSN port deliberately does not list agilex5 as a fallback. A node with
compatible = "altr,socfpga-stmmac-agilex5-tsn", "snps,dwxgmac-2.10] will
therefore never match the if. It falls into the else branch, which holds
the Cyclone5/Arria10/Stratix10 limits.

The TSN board would override the gmac1: ethernet@10820000 node in
arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi. That node has 17
interrupts (macirq, tx-queue-0..7, rx-queue-0..7) and dma-coherent.

If a board DTS switches gmac1 to the TSN compatible, wouldn't it fail
dtbs_check even though it describes the hardware correctly?

In the companion driver patch, socfpga_agilex5_tsn_gmac_setup_plat_dat()
calls socfpga_agilex5_setup_plat_dat() and changes only mac_interface.
That suggests the MAC-side constraints match plain agilex5. Would
something like this work instead:

          contains:
            enum:
              - altr,socfpga-stmmac-agilex5
              - altr,socfpga-stmmac-agilex5-tsn

[Severity: Low]
At this commit, socfpga_dwmac_match in
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c has no entry for
altr,socfpga-stmmac-agilex5-tsn.

Would a node using the new compatible bind through the
snps,dwxgmac-2.10 entry in dwmac_generic_match instead? That path would
skip the SoCFPGA sysmgr, reset and platform data setup.

The next patch in the series, "net: stmmac: dwmac-socfpga: Add support
for Agilex5 TSN GMAC with FPGA converter", adds the match entry. No
in-tree DTS uses the new compatible before that patch.

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260923021823.46649-1-muhammad.nazim.amirul.nazle.asmade%40altera.com

Re: [PATCH net-next 2/2] net: stmmac: dwmac-socfpga: Add support for Agilex5 TSN GMAC with FPGA converter

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 3 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 2 · Low: 1

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] The DT binding's allOf conditional was not updated for the new
  compatible.
- [Medium] socfpga_agilex5_tsn_gmac_setup_plat_dat() rewrites every RGMII
  variant (rgmii, rgmii-id, rgmii-rxid, rgmii-txid) to…
- [Low] socfpga_get_plat_phymode() (dwmac-socfpga.c:76-79) now returns
  dwmac->mac_interface, the MAC-side interface selector, instead of…

--

net: stmmac: dwmac-socfpga: Add support for Agilex5 TSN GMAC with FPGA converter

This adds an "altr,socfpga-stmmac-agilex5-tsn" compatible for an Agilex5
board that has an FPGA GMII-to-RGMII converter between gmac1 and its PHY.
The new setup_plat_dat callback reuses the Agilex5 setup and forces GMII
for the MAC interface selector. It also rewrites any RGMII phy_interface
to plain RGMII.

> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
> index 1d7f0a57d2889..0632105b420f1 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
> @@ -69,12 +69,13 @@ 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 phy_interface_t socfpga_get_plat_phymode(struct socfpga_dwmac *dwmac)
>  {
> -	return dwmac->plat_dat->phy_interface;
> +	return dwmac->mac_interface;
>  }

[Severity: Low]
This isn't a bug, but socfpga_get_plat_phymode() now returns the MAC-side
interface selector, not plat_dat->phy_interface. The comment in
socfpga_gen10_set_phy_mode() was not changed:

	/* Overwrite val to GMII if splitter core is enabled. The phymode here
	 * is the actual phy mode on phy hardware, but phy interface from
	 * EMAC core is GMII.
	 */

With the TSN ops, phymode is GMII and the PHY hardware runs RGMII, so
this comment now says the opposite of what happens.

Could the helper be renamed? The comments in socfpga_gen5_set_phy_mode()
and socfpga_gen10_set_phy_mode() would also need updating to match.

[ ... ]

> @@ -670,10 +673,28 @@ static const struct socfpga_dwmac_ops socfpga_agilex5_ops = {
>  	.setup_plat_dat = socfpga_agilex5_setup_plat_dat,
>  };
>  
> +static void socfpga_agilex5_tsn_gmac_setup_plat_dat(struct socfpga_dwmac *dwmac)
> +{
> +	struct plat_stmmacenet_data *plat_dat = dwmac->plat_dat;
> +
> +	socfpga_agilex5_setup_plat_dat(dwmac);
> +
> +	/* FPGA converter supplies RGMII delays; MAC uses GMII, PHY gets plain RGMII */
> +	dwmac->mac_interface = PHY_INTERFACE_MODE_GMII;
> +	if (phy_interface_mode_is_rgmii(plat_dat->phy_interface))
> +		plat_dat->phy_interface = PHY_INTERFACE_MODE_RGMII;
> +}

[Severity: Medium]
Should phy-mode values that this hardware cannot support be rejected here?
At the moment every RGMII variant is turned into plain RGMII.

The commit message says the FPGA converter provides both the TX and RX
delays. Under the phy-mode rules in ethernet-controller.yaml, that leaves
"rgmii-id" as the only consistent DT value. "rgmii" means the PCB already
provides both delays. "rgmii-txid" and "rgmii-rxid" mean the PCB provides
one of them. The binding also says:

  # link. Thus the MAC should report a fatal error for any modes which
  # cannot be supported.

stmmac already has a path for this in stmmac_pltfr_probe():

	if (plat->has_internal_tx_delay || plat->has_internal_rx_delay) {
		plat->phy_interface =
			phy_fix_phy_mode_for_mac_delays(plat->phy_interface,
							plat->has_internal_tx_delay,
							plat->has_internal_rx_delay);
		if (plat->phy_interface == PHY_INTERFACE_MODE_NA)
			return dev_err_probe(&pdev->dev, -EINVAL,
					     "unsupported phy interface mode\n");
	}

When both delays are internal, phy_fix_phy_mode_for_mac_delays() converts
rgmii-id to rgmii. For any other mode it returns PHY_INTERFACE_MODE_NA.

This patch does its own conversion instead. A DT with phy-mode = "rgmii",
"rgmii-txid" or "rgmii-rxid" then probes with no error. The converter then
adds its own delay on top of the PCB delay.

The phy-mode enum in altr,socfpga-stmmac.yaml accepts all four RGMII
variants, so dtbs_check won't catch this either.

Would setting plat_dat->has_internal_tx_delay and has_internal_rx_delay
work here? That would let stmmac_pltfr_probe() do the conversion and the
validation.

> +
> +static const struct socfpga_dwmac_ops socfpga_agilex5_tsn_gmac_ops = {
> +	.set_phy_mode = socfpga_gen10_set_phy_mode,
> +	.setup_plat_dat = socfpga_agilex5_tsn_gmac_setup_plat_dat,
> +};
> +
>  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_agilex5_ops },
> +	{ .compatible = "altr,socfpga-stmmac-agilex5-tsn", .data = &socfpga_agilex5_tsn_gmac_ops },

[Severity: Medium]
Does the allOf conditional in the binding also need the new compatible?

In Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml, the if
block matches only the plain Agilex5 string:

  - if:
      properties:
        compatible:
          contains:
            const: altr,socfpga-stmmac-agilex5
    then:
      properties:
        interrupts:
          minItems: 17
        ...
        dma-coherent: true
    else:
      properties:
        interrupts:
          maxItems: 1

        interrupt-names:
          maxItems: 1

        dma-coherent: false

The earlier binding patch in this series added
altr,socfpga-stmmac-agilex5-tsn to select and to the compatible enum. It
also says agilex5 should not be used as a fallback. A node with
"altr,socfpga-stmmac-agilex5-tsn", "snps,dwxgmac-2.10" therefore gets the
else constraints.

The driver treats this compatible as full Agilex5 XGMAC hardware. It calls
socfpga_agilex5_setup_plat_dat(), which sets up the XGMAC core, TSO, TBS
on TX queues 6/7 and cross-timestamping. The gmac1 node in
socfpga_agilex5.dtsi, which the TSN board overrides, has 17 interrupts and
dma-coherent.

Won't dtbs_check reject a correct TSN gmac1 node, and accept one with a
single interrupt and no dma-coherent? Should the if block match both
strings, for example:

          contains:
            enum:
              - altr,socfpga-stmmac-agilex5
              - altr,socfpga-stmmac-agilex5-tsn

>  	{ }
>  };
>  MODULE_DEVICE_TABLE(of, socfpga_dwmac_match);

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260923021823.46649-1-muhammad.nazim.amirul.nazle.asmade%40altera.com