On Thu, Sep 02, 2021 at 01:50:50AM +0300, Vladimir Oltean wrote: > The central point of that discussion is that DSA seems "broken" for > expecting the PHY driver to probe immediately on PHYs belonging to the > internal MDIO buses of switches. A few suggestions were made about what > to do, but some were not satisfactory and some did not solve the problem. I think you need to describe the mechanism here. Why wouldn't a PHY belonging to an internal MDIO bus of a switch not probe immediately? What resources may not be available? If we have a DSA driver that tries to probe the PHYs before e.g. the interrupt controller inside the DSA switch has been configured, aren't we just making completely unnecessary problems for ourselves? Wouldn't it be saner to ensure that the interrupt controller has been setup and become available prior to attempting to setup anything that relies upon that interrupt controller? >From what I see of Marvell switches, the internal PHYs only ever rely on internal resources of the switch they are embedded in. External PHYs to the switch are a different matter - these can rely on external clocks, and in that scenario, it would make sense for a deferred probe to cause the entire switch to defer, since we don't have all the resources for the switch to be functional (and, because we want the PHYs to be present at switch probe time, not when we try to bring up the interface, I don't see there's much other choice.) Trying to move that to interface-up time /will/ break userspace - for example, Debian's interfaces(8) bridge support will become unreliable, and probably a whole host of other userspace. It will cause regressions and instability to userspace. So that's a big no. Maybe I'm missing exactly what the problem is... -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
