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:

quoted

quoted

+ * 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