On 1/7/2026 10:43 pm, Andrew Lunn wrote:

On Tue, Jun 30, 2026 at 06:31:08AM -0700, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:

quoted

From: Nazim Amirul <redacted>

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

Hi Maxime, Andrew

Thanks for the reviews!

Hi Andrew,

The challenge with using compatible is that the TSN Config2 board has 
two ports — only gmac1 uses the GMII-to-RGMII converter, while gmac2 
connects directly to its PHY. A board-level compatible check would need 
additional logic to know which port to apply the GMII override to.

With mac-mode, the configuration is per-port in the DTS — consistent 
with how altr,emac-splitter works today. I also addressing Maxime's 
feedback in v2 by unifying the splitter and mac-mode code paths.

BR,
Nazim