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]

Message-ID: <CAJKO-jb7sbzCxPCj75zcZHhdn3xSnuzKu7pSq5dMDxj1tj7LqA@mail.gmail.com>
Date:   Fri, 8 Jan 2021 17:32:57 -0500
From:   Brian Silverman <silvermanbri@...il.com>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org
Subject: 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 <f.fainelli@...il.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