quoted

quoted

How many different boards do you have you can test with? Do you only
have access to RDKs? Or do you have a test farm of customer boards
for regression testing. I would throw the patchset at as many boards
as you can to make sure there are no regressions.

I synced with Jacky offline a few times, and I'm happy to test the
patches on my Facebook Network OpenBMC platforms.

Hi Jacky,

Looking forward to your v5, and please don't hesitate to ping me
offline if you need more info about my test hardware.

Hi Andrew,

Thank you for your suggestions and feedback.
I will update the patches based on our discussion in the next version.

Hi Tao,

Thank you for your support.
Once I have version 5 ready, I will reach out to you. I appreciate your help in
verifying the patches on your hardware.

Hi Andrew,

I miss one condition is using fixed-link property.
In ftgmac100, there are RGMII, NC-SI and fixed-link property.
On RGMII, we have solution on dedicated PHY, but there is an issue on fixed-link
property.

Example on dedicated PHY.
The driver can pass the "rgmii-id" to tell PHY driver to enable the internal delay on
PHY side. Therefore, we can force to disable RGMII delay on MAC side.
But there is not any driver when using fixed-link property, which means
no body can tell the outside device, like switch or MAC-to-MAC, to enable the internal
delay on them. Also mean the phy-mode in fixed-link case is not used.

Therefore, could we ignore the RGMII delay on MAC side when the ftgmac100 driver gets
the fixed-link property? Just keep the original delay value?

Thanks,
Jacky