On 9/30/21 1:14 PM, Saravana Kannan wrote:

On Thu, Sep 30, 2021 at 1:06 PM Florian Fainelli [off-list ref] wrote:

quoted

On 9/30/21 12:48 PM, Saravana Kannan wrote:

quoted

On Thu, Sep 30, 2021 at 12:38 PM Andrew Lunn [off-list ref] wrote:

quoted

quoted

Btw, do we have non-DSA networking devices where fw_devlink=on
delaying PHY probes is causing an issue?

I don't know if issues have been reported, but the realtek driver has
had problems in the past when the generic driver is used. Take a look
at r8169_mdio_register(), it does something similar to DSA.

Does it have the issue of having the PHY as its child too and then
depending on it to bind to a driver? I can't tell because I didn't
know how to find that info for a PCI device.

Yes, r8169 includes a MDIO bus controller, and the PHY is internal to
the Ethernet MAC. These are AFAIR the relevant changes to this discussion:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=16983507742cbcaa5592af530872a82e82fb9c51
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=11287b693d03830010356339e4ceddf47dee34fa

quoted

quoted

What is going to make things interesting is that phy_attach_direct()
is called in two different contexts. During the MAC drivers probe, it
is O.K. to return EPROBE_DEFER, and let the MAC driver try again
later, if we know there is a specific PHY driver for it. But when
called during the MAC drivers open() op, -EPROBE_DEFER is not
allowed. What to do then is an interesting question.

Yeah, basically before doing an open() it'll have to call an API to
say "just bind with whatever you got". Or something along those lines.
I already know how to get that to work. I'll send some RFC soonish (I
hope).

I don't think this is going to scale, we have dozens and dozens of
drivers that connect to the PHY during ndo_open().

Whichever code calls ->ndo_open() can't that mark all the PHYs that'll
be used as "needs to be ready now"? In any case, if we can have an API
that allows a less greedy Generic PHY binding, we could slowly
transition drivers over or at least move them over as they hit issues
with Gen PHY. Anyway, I'll think discussing it over code would be
easier. I'll also have more context as I try to make changes. So,
let's continue this on my future RFC.

It is the same API that is being used whether you connect to the PHY at
ndo_open() time or whether you do that during the parent's ->probe()
fortunately or unfortunately. Now we could set a flag in either case,
and hope that it addresses both situations?

Being able to be selective about the Ethernet PHY driver is being used
is actually a good idea, there are plenty of systems out there whereby
using the Generic PHY driver will not lead to a functional Ethernet
link, if we could say "I want my dedicated driver, and not Generic PHY"
that would actually help some cases, too.
-- 
Florian