回覆: [PATCH net-next v6 0/5] Add AST2600 RGMII delay into ftgmac100

[Jacky Chou]

Hi Andrew,

Thank you for your reply.

> On Mon, Mar 02, 2026 at 06:24:27PM +0800, Jacky Chou wrote:
> > This patch series adds support for configuring RGMII internal delays
> > for the Aspeed AST2600 FTGMAC100 Ethernet MACs.
> 
> I've been thinking about this some more. And i would like to propose a
> completely different solution.
> 
> What we are trying to achieve is allowing the correct phy-mode to be used in
> DT, rgmii-id. Being able to specify internal delays is nice to have, but for most
> platforms should not be needed. It is only needed for badly designed boards
> where the designer of the PCB did not take care with the length of the traces.
> 
> Part of the problem is that the MAC driver is not actually "broken". It does
> what we recommend, read the phy-mode value from DT, and pass it to the PHY.
> The real issue is that the bootloader enabled delays in the MAC, behind the
> MAC drivers back. Because the MAC driver is not "broken", it is hard to "fix"
> the issue in the MAC driver.
> 
> So lets solve this in the bootloader. I suggest you patch the bootloader to no
> longer enable the delays in the MAC. It also needs to patch the DT blob. If the
> blob says "rgmii", change it to "rgmii-id". u-boot should be able to do this.
> 
> That should give backwards compatibility:
> 
> * Existing DT blobs with old bootloader gain the delays in the MAC.
> 
> * Existing DT blobs with the new bootloader gain delays in the PHY.
> 
> * For new boards being added to Linux, we NACK them with "rgmii", tell
>   the developer to upgrade the bootloader, and use the correct
>   rgmii-id. This is a power we do have.
> 
> * Developers of existing .dts files can submit patches to replace
>   "rgmii" with "rgmii-id" once they are happy all platforms have had
>   their bootloader upgraded. That might be never, since developers are
>   lazy, and we cannot force this on them.
> 

In the current ftgmac100 driver, there is no logic to configure MAC internal delay.
All MAC delay settings are configured in U-Boot, and those delay values are derived from the DT used in U-Boot.

As a result:
*The phy-mode in the Linux DT matches the one used in U-Boot.
*Existing AST2600 device trees — including Aspeed’s EVB DT — do not use "rgmii-id".

Before v6 of this series, we discussed introducing MAC internal delay configuration into the ftgmac100 driver.
However, this change would affect all existing DTs, because:
If rx-internal-delay-ns / tx-internal-delay-ns are not present, according to the YAML binding defaults,
MAC internal delay would be disabled.

This would unintentionally change the behavior of existing platforms.
Therefore, starting from v6, the approach evolved into:
* Checking the relationship between the current MAC delay and the phy-mode
* Deciding whether to:
 * Modify the MAC delay, or
 * Preserve the existing MAC delay setting

In fact, in our SDK (U-Boot):
The AST2600 EVB DT has already been updated to use "rgmii-id".
MAC internal delay is explicitly disabled (set to 0 ns).
However, existing deployed platforms will not update their MAC delay configuration simply because of these changes.

For AST2600, we need to maintain backward compatibility in the Linux ftgmac100 driver.
The behavior is:
For old DTs:
The driver determines whether the existing MAC delay should be preserved.
It may attempt to convert to "rgmii-id" and disable MAC internal delay only when safe.
However, if the old DT uses fixed-link, we must preserve the original MAC delay,
Because we cannot propagate phy-mode to modify the external device’s state.
For new DTs:
The driver configures MAC internal delay based on:
rx-internal-delay-ns
tx-internal-delay-ns
The driver then propagates the phy-mode to the PHY.

After completing AST2600 RGMII delay handling, we plan to patch the AST2700 platform.
For AST2700:
U-Boot will consistently use "rgmii-id".
MAC internal delay will be disabled in U-Boot.
Linux will follow the AST2600 "new DT" model:
* Configure MAC internal delay according to rx/tx-internal-delay-ns
* Propagate phy-mode to the PHY
This ensures the platform is implemented cleanly according to the discussed direction, without legacy compatibility constraints.

Thanks,
Jacky