> > > Fixing MAC drivers to interpret the values without > > > "id" to mean that there is a delay on the PCB will break existing Device Trees, > > > so that's no good. > > > > You need to look at it broken driver by broken driver. I _think_ the > > Aspeed case can be fixed. Others we need to look at the details. Maybe > > in some cases we do need to add a warning to the device tree binding > > the driver is FUBAR and has special, broken meaning for 'rgmii'. > > I don't know about Aspeed (maybe you're mixing something up, or I'm not aware of > something?) - in the case of the TI driver I'm dealing with, this is indeed > possible to fix up because the MAC always adds a delay, it is not configurable. The Aspeed driver also gets RGMII delays wrong. And there is an ongoing discussion about how to fix it. The discussions there probably apply to most drivers which get RGMII delays wrong. Following the discussions on how RGMII is broken in other places might help you fix the TI driver. > The whole point of my suggestions is to allow fixing the drivers while staying > compatible with old, broken Device Trees. If we could add a property 'phy-mode- > is-fubar' to old Device Trees, we could just fix them instead - but we can only > fix in-tree DTS, and it will only have an effect on systems that update their > DTBs with their kernel, so I believe this simply isn't an option because of > backwards compat guarantees for Device Trees. So you need the TI driver to accept the broken 'rgmii', and the correct 'rgmii-id'. You say the MAC hardware always adds the delay. So 1) Patch the driver to test for 'rgmii', and issues a warning that the DT is wrong and needs updating. 2) Add the missing masking of the value passed to the PHY. Since the MAC driver is adding the delays, it needs to modify the phy_interface_t passed to phy_connect(), masking out the delays the MAC is adding. This is an established procedure for MACs which implement the delays, rather than ask the PHY to do it. It then becomes possible to use the correct 'rgmii-id' value. 3) Patch the TI .dts files to use the correct rgmii-id. That makes the warnings added in 1) go away. This is a lot simpler than the Aspeed case, but the basic discussion taking place with the Aspeed driver would give you useful background. Andrew
