quoted

quoted

This is an optional property. If it does not exist, you have an old
DT blob. It is not an error. So you need to do different things
depending on what the error code is. If it does not exist, just
return 0 and leave the hardware alone. If it is some other error report it,

and abort the probe.

quoted

quoted

Based on this for next version, I want to move the "aspeed,scu" from dtsi to

dts.

quoted

Change it to optional and accord it whether existed to decide it is
old or new DT blob.

I think that is the easy way out, not necessarily the correct way.

Agreed.
That's easy to implement adding support RGMII delay configuration for AST2600.
According to aspeed,scu property if it is a new dts.
If it is old dts, ignore delay setting flow.
If new one, configure the corresponding value from tx/rx-internal-delay-ps
properties.

At first, I would just like to support for new dts based on AST2600.
The existed dts in kernel is as legacy dts for AST2600 and try to bypass
them. Therefore, I tried to use new compatible or aspeed,scu property to identify
which new dts is.

All systems have the aspeed,scu, so it should really be in the .dtsi file.

What are you really trying to solve? That the DT blob says "rgmii", but the
bootloader has configured the MAC to add delays? You should be able to test
for that condition. If it is found, issue as warning, and treat phy-mode as
'rgmii-id'. If the DT blob says 'rgmii-id' and the MAC is configured to add the
delays, the system is at least consistent, no need for a warning, disable the
MAC delays and pass _RGMII_ID to the PHY. And if the blob says 'rgmii-id' and
the MAC is not adding delays, no need to touch the MAC delay, and pass
_RGMII_ID to the PHY.

Are there any mainline DT .dts files which say rgmii-txid, or rgmii-rxid? They
would be rather odd, but occasionally you see them.
Assuming there are not lots of them, i would probably just leave everything as
is.

Based on the above information, I have attempted to outline my understanding.
1. 'rgmii' + MAC delay:
Add warming, keep MAC delay and pass "rgmii-id" to PHY driver.

2. 'rgmii-id' + MAC delay:
disable MAC delay and pass "rgmii-id" to PHY driver

3. 'rgmii-id' + no MAC delay:
Keep disabling MAC delay and pass "rgmii-id" to PHY driver

4. 'rgmii-txid' or 'rgmii-rxid':
Keep original setting


I have some idea to discuss with you.
1. On 'rgmii', I want to add warming and directly disable MAC delay and pass 'rgmii-id' 
to PHY driver.

2. On 'rgmii-id', ignore if enabling MAC delay, all disable MAC delay and pass ' rgmii-id'
to PHY driver.

3. On 'rgmii-txid' or 'rgmii-rxid', keep the above item 4.

Actually, it's difficult for the driver to determine whether the MAC delay is enabled or not.
Our design doesn't use a single bit to indicate the delay state. Instead, the delay setting is 
derived from the user's configured delay value.

From what I understand, when the TX delay value is set to zero, the data and clock signals 
are almost aligned to the edge - which likely means the MAC TX delay is disabled.

Therefore, I'd prefer the driver to simply configure the MAC delay based on the phy-mode 
and the tx/rx-internal-delay-ps properties.

As you mentioned before, the v4 behavior results in a network interface that can successfully 
probe but does not actually work.
So, I'm also considering another approach on the AST2600:
to not support rgmii, rgmii-txid, or rgmii-rxid modes directly.
If any of these are encountered, the driver could automatically treat them as rgmii-id and issue 
a warning.

Thanks,
Jacky