[PATCH net-next v4 4/4] net: ftgmac100: Add RGMII delay support for AST2600

[Jacky Chou]

> > > 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.
> > >
> >
> > Based on this for next version, I want to move the "aspeed,scu" from dtsi to
> dts.
> > 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.