netdev - Re: MDIO over I2C driver driver probe dependency issue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 8 Jan 2021 14:11:31 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Andrew Lunn <andrew@...n.ch>,
        Brian Silverman <silvermanbri@...il.com>
Cc:     netdev@...r.kernel.org
Subject: Re: MDIO over I2C driver driver probe dependency issue



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