> Not our board, but the AM62 SoC. From the datasheet: > > "TXC is delayed internally before being driven to the RGMII[x]_TXC pin. This > internal delay is always enabled." So enabling the TX delay on the PHY side > would result in a double delay. phy-mode describes the board. If the board does not have extra long clock lines, phy-mode should be rgmii-id. The fact the MAC is doing something which no other MAC does should be hidden away in the MAC driver, as much as possible. The MAC driver should return -EINVAL with phy-mode rgmii, or rmgii-rxid, because the MAC driver is physically incapable of being used on a board which has extra long TX clock lines, which 'rmgii' or rgmii-rxid would indicate. Since the MAC driver is forcing the TX delay, it needs to take the value returned from of_get_phy_mode() and mask out the TX bit before passing it to the PHY. Now, it could be that history has got in the way. There are boards out there which have broken DT but work. Fixing the MAC driver to do the correct thing will break those boards. Vendors with low quality code which works, but not really. ~/linux/arch/arm64/boot/dts/ti$ grep rgmii k3-am625-* k3-am625-beagleplay.dts: phy-mode = "rgmii-rxid"; k3-am625-sk.dts: phy-mode = "rgmii-rxid"; Yep, these two have broken DT, they don't describe the board correctly. O.K. Can we fix this for you board? Yes, i think we can. If you take rmgii-rxid, aka PHY_INTERFACE_MODE_RGMII_RXID, and mask out the TX, you still get PHY_INTERFACE_MODE_RGMII_RXID. If you take rgmii-id, a.k.a. PHY_INTERFACE_MODE_RGMII_ID and mask out the TX, you get PHY_INTERFACE_MODE_RGMII_RXID, which is what you want. Please produce a patch to the MAC driver, explaining the horrible mess the vendor made, and how this fixes it, but should also not break other boards. > No such defaults exist in the DP83867 driver. If any rgmii-*id mode is used, the > corresponding delays *must* be specified in the DTB: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/phy/dp83867.c#n532 That is bad, different to pretty every other PHY driver :-( If you want, you could patch this driver as well, make it default to 2ns if delays are asked for. Andrew --- pw-bot: cr
