On Wed, Jun 17, 2020 at 01:52:01PM +0200, Helmut Grohne wrote: > On Wed, Jun 17, 2020 at 01:40:25PM +0200, Russell King - ARM Linux admin > wrote: > > > For a fixed-link, the validation function is never called. Therefore, it > > > cannot reject PHY_INTERFACE_MODE_RGMII. It works in practice. > > > > Hmm, I'm not so sure, but then I don't know exactly what code you're > > using. Looking at mainline, even for a fixed link, you call > > phylink_create(). phylink_create() will spot the fixed link, and > > parse the description, calling the validation function. If that > > fails, it will generate a warning at that point: > > > > "fixed link %s duplex %dMbps not recognised" > > > > It doesn't cause an operational failure, but it means that you end up > > with a zero supported mask, which is likely not expected. > > > > This is not an expected situation, so I'll modify your claim to "it > > works but issues a warning" which still means that it's not correct. > > I do see that warning. I agree with your correction of my claim. Thank > you for your attention to detail. > > So we have two good reasons for not rejecting delay configuration in the > validation function now. > > The remaining open question seems to be whether configuring a delay on a > MAC to MAC connection should cause a failure or a only warning. Do you > have an opinion on that? > > All in-tree bindings of the driver seem to use rmii when they specify a > phy-mode.
This brings up a problem in itself - the phy interface mode is currently defined in terms of a MAC-to-PHY setup, not a MAC-to-MAC setup. With a fixed link, we could be in either a MAC-to-PHY or MAC-to-MAC setup; we just don't know. However, we don't have is access to the PHY (if it exists) in the fixed link case to configure it for the delay. In the MAC-to-MAC RGMII setup, where neither MAC can insert the necessary delay, the only way to have a RGMII conformant link is to have the PCB traces induce the necessary delay. That errs towards PHY_INTERFACE_MODE_RGMII for this case. However, considering the MAC-to-PHY RGMII fixed link case, where the PHY may not be accessible, and may be configured with the necessary delay, should that case also use PHY_INTERFACE_MODE_RGMII - clearly that would be as wrong as using PHY_INTERFACE_MODE_RGMII_ID would be for the MAC-to-MAC RGMII with PCB-delays case. So, I think a MAC driver should not care about the specific RGMII mode being asked for in any case, and just accept them all. I also think that some of this ought to be put in the documentation as guidance for new implementations. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
