* [PATCH net-next v1 1/1] net: phy: clear EEE runtime state in PHY_HALTED/PHY_ERROR
@ 2025-09-09 13:12 Oleksij Rempel
2025-09-09 13:58 ` Andrew Lunn
0 siblings, 1 reply; 4+ messages in thread
From: Oleksij Rempel @ 2025-09-09 13:12 UTC (permalink / raw)
To: Andrew Lunn, Heiner Kallweit, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: Oleksij Rempel, Russell King (Oracle), kernel, linux-kernel, netdev
Clear EEE runtime flags when the PHY transitions to HALTED or ERROR
and the state machine drops the link. This avoids stale EEE state being
reported via ethtool after the PHY is stopped or hits an error.
Suggested-by: Russell King (Oracle) <linux@armlinux.org.uk>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
Related discussion: https://lore.kernel.org/r/aKg7nf8YczCT6N0O@shell.armlinux.org.uk
---
drivers/net/phy/phy.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 13df28445f02..b8963d26af26 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -1555,6 +1555,8 @@ static enum phy_state_work _phy_state_machine(struct phy_device *phydev)
case PHY_ERROR:
if (phydev->link) {
phydev->link = 0;
+ phydev->eee_active = false;
+ phydev->enable_tx_lpi = false;
phy_link_down(phydev);
}
state_work = PHY_STATE_WORK_SUSPEND;
--
2.47.3
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH net-next v1 1/1] net: phy: clear EEE runtime state in PHY_HALTED/PHY_ERROR
2025-09-09 13:12 [PATCH net-next v1 1/1] net: phy: clear EEE runtime state in PHY_HALTED/PHY_ERROR Oleksij Rempel
@ 2025-09-09 13:58 ` Andrew Lunn
2025-09-10 7:08 ` Oleksij Rempel
0 siblings, 1 reply; 4+ messages in thread
From: Andrew Lunn @ 2025-09-09 13:58 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Heiner Kallweit, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Russell King (Oracle),
kernel, linux-kernel, netdev
On Tue, Sep 09, 2025 at 03:12:48PM +0200, Oleksij Rempel wrote:
> Clear EEE runtime flags when the PHY transitions to HALTED or ERROR
> and the state machine drops the link. This avoids stale EEE state being
> reported via ethtool after the PHY is stopped or hits an error.
One obvious question, why is EEE special? We have other state in
phydev which is not valid when the link is down. Are we setting speed
and duplex to UNKNOWN? lp_advertising, mdix, master_slave_state?
So while i agree it is nice not to show stale EEE state, maybe we
should not be showing any stale state and this patch needs extending?
Andrew
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH net-next v1 1/1] net: phy: clear EEE runtime state in PHY_HALTED/PHY_ERROR
2025-09-09 13:58 ` Andrew Lunn
@ 2025-09-10 7:08 ` Oleksij Rempel
2025-09-11 12:22 ` Andrew Lunn
0 siblings, 1 reply; 4+ messages in thread
From: Oleksij Rempel @ 2025-09-10 7:08 UTC (permalink / raw)
To: Andrew Lunn
Cc: Heiner Kallweit, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Russell King (Oracle),
kernel, linux-kernel, netdev
On Tue, Sep 09, 2025 at 03:58:32PM +0200, Andrew Lunn wrote:
> On Tue, Sep 09, 2025 at 03:12:48PM +0200, Oleksij Rempel wrote:
> > Clear EEE runtime flags when the PHY transitions to HALTED or ERROR
> > and the state machine drops the link. This avoids stale EEE state being
> > reported via ethtool after the PHY is stopped or hits an error.
>
> One obvious question, why is EEE special? We have other state in
> phydev which is not valid when the link is down. Are we setting speed
> and duplex to UNKNOWN? lp_advertising, mdix, master_slave_state?
>
> So while i agree it is nice not to show stale EEE state, maybe we
> should not be showing any stale state and this patch needs extending?
I decided to send the first step patch for the agreed subset (EEE
flags), so it can be merged faster.
As a follow-up I would propose a separate patch which clears additional
link-resolved state when the PHY enters HALTED, for example:
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -1552,6 +1552,16 @@ static enum phy_state_work _phy_state_machine(struct phy_device *phydev)
}
break;
case PHY_HALTED:
+ if (phydev->link) {
+ if (phydev->autoneg == AUTONEG_ENABLE) {
+ phydev->speed = SPEED_UNKNOWN;
+ phydev->duplex = DUPLEX_UNKNOWN;
+ }
+ if (phydev->master_slave_state != MASTER_SLAVE_STATE_UNSUPPORTED)
+ phydev->master_slave_state = MASTER_SLAVE_STATE_UNKNOWN;
+ phydev->mdix = ETH_TP_MDI_INVALID;
+ linkmode_zero(phydev->lp_advertising);
+ }
case PHY_ERROR:
if (phydev->link) {
phydev->link = 0;
Would this approach be acceptable, or do you see hidden issues with clearing
these extra fields?
Best Regards,
Oleksij
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH net-next v1 1/1] net: phy: clear EEE runtime state in PHY_HALTED/PHY_ERROR
2025-09-10 7:08 ` Oleksij Rempel
@ 2025-09-11 12:22 ` Andrew Lunn
0 siblings, 0 replies; 4+ messages in thread
From: Andrew Lunn @ 2025-09-11 12:22 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Heiner Kallweit, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Russell King (Oracle),
kernel, linux-kernel, netdev
> As a follow-up I would propose a separate patch which clears additional
> link-resolved state when the PHY enters HALTED, for example:
This is good. Maybe mention in the commit message there will be a
follow up for other state variables.
Thanks
Andrew
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2025-09-11 12:23 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-09-09 13:12 [PATCH net-next v1 1/1] net: phy: clear EEE runtime state in PHY_HALTED/PHY_ERROR Oleksij Rempel
2025-09-09 13:58 ` Andrew Lunn
2025-09-10 7:08 ` Oleksij Rempel
2025-09-11 12:22 ` Andrew Lunn
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®