netdev - Re: [PATCH net-next v1 1/1] net: phy: clear EEE runtime state in PHY_HALTED/PHY

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aMEj8vjJY4h6kYbN@pengutronix.de>
Date: Wed, 10 Sep 2025 09:08:34 +0200
From: Oleksij Rempel <o.rempel@...gutronix.de>
To: Andrew Lunn <andrew@...n.ch>
Cc: Heiner Kallweit <hkallweit1@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	"Russell King (Oracle)" <linux@...linux.org.uk>,
	kernel@...gutronix.de, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [PATCH net-next v1 1/1] net: phy: clear EEE runtime state in
 PHY_HALTED/PHY_ERROR

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 |