On Tue, Jun 04, 2019 at 10:58:41PM +0300, Vladimir Oltean wrote: > Hi, > > I've been wondering what is the correct approach to cut the Ethernet link > when the user requests it to be administratively down (aka ip link set dev > eth0 down). > Most of the Ethernet drivers simply call phy_stop or the phylink equivalent.
The first requirement is that phylink_start() is required to be called in the ndo_open callback, and phylink_stop() is required to be called in the ndo_stop callback - this is because when a SFP is used, it has other effects beyond managing the PHY. phylink_start() and phylink_stop() call the appropriately phylib functions, and what happens to the PHY is up to phylib. Whether a PHY has its link brought down or not is not set in stone: some network cards, particularly those that do not use phylib, do not bring the link down when the interface is brought down - doing so, allows for (eg) a faster boot, and of course bringing an interface up is faster if the link is already established. Then there's the question about when the PHY is attached to the network device. Some drivers attach the PHY in their probe function, others attach the PHY in their ndo_open method. If the PHY is attached in the ndo_open method, then the PHY must be detached(disconnected) in the ndo_stop method - basically, ndo_stop must reverse everything that ndo_open did. > I see the ability to be able to put the PHY link administratively down a > desirable feat. If it's left to negotiate/receive traffic etc while the MAC > driver isn't completely set up and ready, in theory a lot of processing can > happen outside of the operating system's control. Normally the PHY receives traffic, and passes it to the MAC which just ignores the signals it receives from the PHY, so no processing beyond the PHY receiving the traffic happens. Ultimately, whether you want the PHY to stay linked or not linked is, imho, a policy that should be set by the administrator (consider where a system needs to become available quickly after boot vs a system where power saving is important.) We don't, however, have a facility to specify that policy though. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up
