On Wed, 5 Jun 2019 at 01:59, Russell King - ARM Linux admin <li...@armlinux.org.uk> wrote: > > On Wed, Jun 05, 2019 at 01:44:08AM +0300, Vladimir Oltean wrote: > > You caught me. > > > > But even ignoring the NIC case, isn't the PHY state machine > > inconsistent with itself? It is ok with callink phy_suspend upon > > ndo_stop, but it won't call phy_suspend after phy_connect, when the > > netdev is implicitly stopped? > > The PHY state machine isn't inconsistent with itself, but it does > have strange behaviour. > > When the PHY is attached, the PHY is resumed and the state machine > is in PHY_READY state. If it goes through a start/stop cycle, the > state machine transitions to PHY_HALTED and attempts to place the > PHY into a low power state. So the PHY state is consistent with > the state machine state (we don't end up in the same state but with > the PHY in a different state.) > > What we do have is a difference between the PHY state (and state > machine state) between the boot scenario, and the interface up/down > scenario, the latter behaviour having been introduced by a commit > back in 2013: > > net: phy: suspend phydev when going to HALTED > > When phydev is going to HALTED state, we can try to suspend it to > safe more power. phy_suspend helper will check if PHY can be suspended, > so just call it when entering HALTED state. > > -- > 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
I am really not into the PHYLIB internals, but basically what you're telling me is that running "ip link set dev eth0 down" is a stronger/more imperative condition than not running "ip link set dev eth0 up"... Does it also suspend the PHY if I put the interface down while it was already down? -Vladimir
