linux-kernel - Re: [PATCH net 2/2] net: pcs: xpcs: actively unset DW_VR_MII_DIG_CTRL1_2G5

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250115145145.4jdajfaksyfkx5zh@skbuf>
Date: Wed, 15 Jan 2025 16:51:45 +0200
From: Vladimir Oltean <vladimir.oltean@....com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: netdev@...r.kernel.org, Jose Abreu <Jose.Abreu@...opsys.com>,
	Andrew Lunn <andrew@...n.ch>,
	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>,
	Voon Weifeng <weifeng.voon@...el.com>,
	Michael Sit Wei Hong <michael.wei.hong.sit@...el.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH net 2/2] net: pcs: xpcs: actively unset
 DW_VR_MII_DIG_CTRL1_2G5_EN for 1G SGMII

On Wed, Jan 15, 2025 at 02:44:52PM +0000, Russell King (Oracle) wrote:
> On Tue, Jan 14, 2025 at 06:47:21PM +0200, Vladimir Oltean wrote:
> > xpcs_config_2500basex() sets DW_VR_MII_DIG_CTRL1_2G5_EN, but
> > xpcs_config_aneg_c37_sgmii() never unsets it. So, on a protocol change
> > from 2500base-x to sgmii, the DW_VR_MII_DIG_CTRL1_2G5_EN bit will remain
> > set.
> > 
> > Fixes: f27abde3042a ("net: pcs: add 2500BASEX support for Intel mGbE controller")
> > Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>
> 
> Reviewed-by: Russell King (Oracle) <rmk+kernel@...linux.org.uk>
> 
> Thanks!
> 
> I wonder whether, now that we have in-band capabilities, and thus
> phylink knows whether AN should be enabled or not, whether we can
> simplify all these different config functions and rely on the
> neg_mode from phylink to configure in-band appropriately.

I don't understand, many sub-functions of xpcs_do_config() use neg_mode
already.

If you're talking about replacing compat->an_mode with something derived
partially from the neg_mode and partially from state->interface, then in
principle yes, sure, but we will need new neg_modes for clause 73
auto-negotiation (to replace DW_AN_C73), plus appropriate handling in phylink.