linux-kernel - Re: [PATCH net-next v2 1/1] net: dsa: microchip: Remove ineffective checks from ksz_set_mac

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: <aAu83HGXOxQ6H8on@shell.armlinux.org.uk>
Date: Fri, 25 Apr 2025 17:48:28 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Oleksij Rempel <o.rempel@...gutronix.de>
Cc: "David S. Miller" <davem@...emloft.net>, Andrew Lunn <andrew@...n.ch>,
	Eric Dumazet <edumazet@...gle.com>,
	Florian Fainelli <f.fainelli@...il.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Vladimir Oltean <olteanv@...il.com>,
	Woojung Huh <woojung.huh@...rochip.com>, kernel@...gutronix.de,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	UNGLinuxDriver@...rochip.com
Subject: Re: [PATCH net-next v2 1/1] net: dsa: microchip: Remove ineffective
 checks from ksz_set_mac_eee()

On Fri, Apr 25, 2025 at 06:31:18PM +0200, Oleksij Rempel wrote:
> Additionally, it seems that setting eee_enabled automatically based on
> advertisement in phy_probe() is no longer appropriate.
> If you agree, I would propose a patch to remove this initialization.

Remember how eee_enabled is implemented. It controls whether we program
the EEE advertisement with the contents of the software advertisement
state, or clear it.

So, if the hardware has a non-zero advertisement, then it is completely
correct that we read the advertisement and set eee_enabled to be true.
The alternative is, we set eee_enabled false and clear the
advertisement.

We can't leave the advertisement and set eee_enabled to be false. That
is inconsistent with the way we handle any attempt to set the
eee_enabled state.

I think the correct approach in this case is to set
config->eee_enabled_default to be true in ksz_phylink_get_caps(),
thereby correcting the bug introduced in March 2024. That has the
effect of setting phy->eee_cfg.tx_lpi_enabled, which means we should
report tx_lpi_enabled as true when reading the EEE state.

For the stable kernels between March 2024 and the integration of
phylink EEE support, a similar approach will be necessary to restore
the pre-March 2024 behaviour, but that will be much harder to correct
as the DSA driver doesn't have an appropriate hook to set that field
at the appropriate time.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!