> Do you have a pointer why setting the delays in the phy is preferred > over setting them in the network driver? In the end this requires us > to have the correct phy driver whereas setting them in the network > driver would just work for any phy driver? One reason is that nearly every other board does it in the PHY. This is something i've been trying to standardize on for years. Another point is that when doing it in the MAC, most MAC drivers get it wrong. RGMII needs 2ns delays on the clock lines. That delay can be provided by the board, making the clock lines longer. Or the MAC or the PHY can add the delays. phy-mode in DT tells you about what the board requires. Your board does not have extra long clock lines, so you need rgmii-id. If the MAC decides to implement the delay, it should modify the value passed to the PHY to be rgmii, to indicate it has added the delays, and the PHY should not. This is what many MAC drivers get wrong, they don't do the masking. By standardizing on the PHY doing the delay, we avoid this, keeping the MAC driver simple, and probably bug free in this respect. There is admittedly some historical confusion here. The design is not the best. If would of been much better if the design would have both phy-mode and mac-mode. As for using genphy, yes it might work, but there is no real guarantee. It is always best you drive the hardware using the driver specific to it. Consider genphy as a fallback which might be good enough that you can ssh into the board and install the correct module. You should not really be using it in production. Andrew
