[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190604225919.xpkykt2z3a7utiet@shell.armlinux.org.uk>
Date: Tue, 4 Jun 2019 23:59:19 +0100
From: Russell King - ARM Linux admin <linux@...linux.org.uk>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Florian Fainelli <f.fainelli@...il.com>,
Andrew Lunn <andrew@...n.ch>,
Heiner Kallweit <hkallweit1@...il.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Ioana Ciornei <ioana.ciornei@....com>
Subject: Re: Cutting the link on ndo_stop - phy_stop or phy_disconnect?
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
Powered by blists - more mailing lists