Re: [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration

[Andrew Lunn <andrew@lunn.ch>]

> I don't think we should associate it to the MAC. In a hardware point of view the
> PSE Power Interfaces are wired the MDIs. It was associated historically to the
> PHY, because, at that time there was no representation of the MDI. Now thanks
> to Maxime there is, so in the future we should associate the PSE control to the
> MDI only. We will already have to keep the PHY association compatibility to not
> break binding API but please do not add another layer of association that will
> increase more compatibility burden for the future.
> 
> As I proposed in another thread, if the PHY can't find the PSE PI, we could
> save the phandle of the PSE PI somewhere in the PHY structure. Then at PSE
> register time, look for each PHY and try to resolve every unresolved phandle.

I still think we should be deferring probe until we have all the parts
available. The question is, how do we actually do that?

We could insist that MACs being used with PSE need to call
phylink_connect() in probe, so we can return EPROBE_DEFER. We might
actually need a new API method, phylink_connect_probe(). That can call
down into phylib, maybe again new API methods, which will not bind
genphy, but return EPROBE_DEFER.

This helps solve this problem. And it puts in place a solution for
other similar problems. We have seen PHY drivers which download
firmware get into a similar situation, genphy used because the
download takes too long. It needs MAC driver changes, which is not
great, but the changes themselves should be easy to do.

I don't think having MDI represented helps us. We still get into the
same situation, open() calls phylink_connect() and there is nothing we
can do except use genphy.

    Andrew