> As previously mentioned, using 'rgmii' will enable EMAC to provide the delay > while disabling the delay for EPHY. So there's won't be double delay. > > Additionally, the current implementation of the QCOM driver code exclusively > supports this mode, with the entire initialization sequence of EMAC designed > and fixed for this specific mode. OK. If it is impossible to disable these delays, you need to validate phy-mode. Only rgmii-id is allowed. Anybody trying to build a board using extra long clock lines is out of luck. It does not happen very often, but there are a small number of boards which do this, and the definitions of phy-mode are designed to support them. > I'm not sure if there's a disagreement about the definition or a > misunderstanding with other vendors. From my understanding, 'rgmii' should > not imply that the delay must be provided by the board, based on both the > definition in the dt-binding file and the implementations by other EMAC > vendors. Most EMAC drivers provide the delay in this mode. Nope. You are wrong. I've been enforcing this meaning for maybe the last 10 years. You can go search the email archive for netdev. Before that, we had a bit of a mess, developers were getting it wrong, and reviewing was not as good. And i don't review everything, so some bad code does get passed me every so often, e.g. if found out today that TI AM62 got this wrong, they hard code TX delays in the MAC, and DT developers have been using rgmii-rxid, not rgmii-id, and the MAC driver is missing the mask operation before calling phy_connect. > I confirmed that there is no delay on the qcs615-ride board., and the QCOM > EMAC driver will adds the delay by shifting the clock after receiving > PHY_INTERFACE_MODE_RGMII. Which is wrong. Because you cannot disable the delay, PHY_INTERFACE_MODE_RGMII should return in EINVAL, or maybe EOPNOTSUPP. Your hardware only supports PHY_INTERFACE_MODE_RGMII_ID, and you need to mask what you pass to phylib/phylink to make it clear the MAC has added the delays. Andrew
