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

[Nazle Asmade, Muhammad Nazim Amirul]

On 1/7/2026 8:47 pm, Andrew Lunn wrote:
>>> # 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
Hi Andrew,

Thank you for the clarification. We agree with your framework in 
principle, but would like to explain why phy-mode = "rgmii" is the 
appropriate description for this specific case.

After getting more information from hw team, for Agilex specific device, 
the RGMII timing delays on this board are provided by an FPGA delay 
chain (Input/Output Delay Chain primitives in the FPGA fabric). The 
reason for using the FPGA rather than the PHY is that the Marvell PHY on 
this board only supports 0ns or 2ns delay steps — too coarse to meet the 
RGMII timing requirements. The FPGA delay chain provides up to 63 steps 
of ~0.1ns precision, which the hardware team has tuned at design time to 
achieve correct signal timing.

This delay is fixed in the FPGA bitstream and is invisible to the Linux 
driver — the driver cannot read, modify, or even detect the delay value 
that was programmed. The driver has no way to know "the MAC is providing 
X nanoseconds of delay."

In this situation, the only meaningful action the driver can take is to 
instruct the PHY not to add its own delays — which phy-mode = "rgmii" 
already achieves correctly. Changing to phy-mode = "rgmii-id" and having 
the driver strip the delay before passing to the PHY would produce the 
same hardware behaviour (PHY adds zero delay), but would add driver 
complexity with no practical benefit, and would misrepresent the FPGA 
delay as a driver-managed MAC delay when it is actually a fixed, 
board-level hardware calibration.

Could you advise if you still prefer the rgmii-id approach given this 
constraint?

BR,
Nazim