On Fri, Jan 08, 2021 at 02:11:31PM -0800, Florian Fainelli 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.
I just looked through the current users of phylink_of_phy_connect().
Most simply do a netdev_err() and return the error code to higher
levels. So apart from the spurious netdev_err() is -EPROBE_DEFER is
returned, they should do the right thing.
mvneta actually looks broken, it prints the error, but keeps going,
plays with WOL setings on the phy and device_set_wake() then returns
the error code.
macb is a bit more complex, but if i'm understanding it correctly, it
should handle -EPROBE_DEFER already, but you will get a spurious
netdev_err() for the -EPROBE_DEFER.
So i think we can fix this, and we should probably do it before there
are more users.
Brian, can you run a modern kernel to test patches, or do you need to
use the Xilinx fork?
Andrew
