Hi Andrew

Thank you for your reply.

quoted

Agree. You are right. This part is used to create a gated clock.
We will configure these RGMII delay in bootloader like U-boot.
Therefore, here does not configure delay again.

quoted

Because AST2600 MAC1/2 RGMII delay setting in scu region is combined
to one 32-bit register,
MAC3/4 is also. I will also use 'aliase' to get MAC index to set delay in scu.

// aspeed-g6.dtsi
aliases {
		..........
		mac0 = &mac0;
		mac1 = &mac1;
		mac2 = &mac2;
		mac4 = &mac3;
	};

I would avoid that, because they are under control of the DT developer. You
sometimes seen the order changed in the hope of changing the interface
names, rather than use a udev script, or systemd naming scheme.

The physical address of each interface is well known and fixed? Are they the
same for all ASTxxxx devices? I would hard code them into the driver to
identify the instance.

The physical address of each interface is all different in all aspeed device.
And they are fixed and known. I can use the address to distinguish the interface.

But first we need to fix what is broken with the existing DT phy-modes etc.

What is the reset default of these SCU registers? 0? So we can tell if the
bootloader has modified it and inserted a delay?

What i think you need to do is during probe of the MAC driver, compare
phy-mode and how the delays are configured in hardware. If the delays in
hardware are 0, assume phy-mode is correct and use it. If the delays are not 0,
compare them with phy-mode. If the delays and phy-mode agree, use them. If
they disagree, assume phy-mode is wrong, issue a dev_warn() that the DT blob
is out of date, and modify phy-mode to match the delays in the hardware,
including a good explanation of what is going on in the commit message to
help those with out of tree DT files. And then patch all the in tree DT files to
use the correct phy-mode.

Agree. I think this method is good. The RGMII delay reset value in SCU is zero.
I can use the reset value to know if the RGMII delay is configured.
If the values are not match the phy-mode, print warning message and apply the 
RGMII delay property if there is in MAC node of dts.

Please double check my logic, just to make sure it is correct. If i have it correct,
it should be backwards compatible. The one feature you loose out on is when
the bootloader sets the wrong delays and you want phy-mode to actually
override it.

When AST2700 comes along, you can skip all this, get it right from the start
and not need this workaround.

Thanks for your friendly reminder.

Thanks,
Jacky