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. Helmut
