Thanks - I will have to keep a local patch to fix this for my needs for the time being.
If in the future if I'm able to do something better (e.g. with a better fw_devlink, which looks interesting), I'll post a patch. But I generally lag the latest kernels by a couple years, so... not any time soon. <and hopefully this time my post doesn't bounce as I've turned off HTML> On Fri, Jan 8, 2021 at 5:11 PM Florian Fainelli <f.faine...@gmail.com> wrote: > > > > On 1/8/2021 1:04 PM, Andrew Lunn wrote: > > On Fri, Jan 08, 2021 at 03:02:52PM -0500, Brian Silverman wrote: > >> Thanks for the responses - I now have a more clear picture of what's going > >> on. > >> (Note: I'm using Xilinx's 2019.2 kernel (based off 4.19). I believe it > >> would > >> be similar to latest kernels, but I could be wrong.) > > > > Hi Brian > > > > macb_main has had a lot of changes with respect to PHYs. Please try > > something modern, like 5.10. > > It does not seem to me like 5.10 will be much better, because we have > the following in PHYLINK: > > int phylink_of_phy_connect(struct phylink *pl, struct device_node *dn, > u32 flags) > ... > phy_dev = of_phy_find_device(phy_node); > /* We're done with the phy_node handle */ > of_node_put(phy_node); > if (!phy_dev) > return -ENODEV; > > Given Brian's configuration we should be returning -EPROBE_DEFER here, > but doing that would likely break a number of systems that do expect > -ENODEV to be returned. However there may be hope with fw_devlink to > create an appropriate graph of probing orders and solve the > consumer/provider order generically. > > Up until now we did not really have a situation like this one where the > MDIO/PHY subsystem depended upon an another one to be available. The > problem does exist, however it is not clear to me yet how to best solve it. > -- > Florian
