On 9/30/21 1:14 PM, Saravana Kannan wrote: > On Thu, Sep 30, 2021 at 1:06 PM Florian Fainelli <f.fainelli@xxxxxxxxx> wrote: >> >> On 9/30/21 12:48 PM, Saravana Kannan wrote: >>> On Thu, Sep 30, 2021 at 12:38 PM Andrew Lunn <andrew@xxxxxxx> wrote: >>>> >>>>> 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 >> >> >>> >>>> >>>> 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
