Re: MDIO over I2C driver driver probe dependency issue

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 [off-list ref] wrote:

On 1/8/2021 1:04 PM, Andrew Lunn wrote:

quoted

On Fri, Jan 08, 2021 at 03:02:52PM -0500, Brian Silverman wrote:

quoted

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