[PATCH net 1/2] net: pcs: xpcs: fix DW_VR_MII_DIG_CTRL1_2G5_EN bit being set for 1G SGMII w/o inband

[PATCH net 1/2] net: pcs: xpcs: fix DW_VR_MII_DIG_CTRL1_2G5_EN bit being set for 1G SGMII w/o inband

[Vladimir Oltean]

On a port with SGMII fixed-link at SPEED_1000, DW_VR_MII_DIG_CTRL1 gets
set to 0x2404. This is incorrect, because bit 2 (DW_VR_MII_DIG_CTRL1_2G5_EN)
is set.

It comes from the previous write to DW_VR_MII_AN_CTRL, because the "val"
variable is reused and is dirty. Actually, its value is 0x4, aka
FIELD_PREP(DW_VR_MII_PCS_MODE_MASK, DW_VR_MII_PCS_MODE_C37_SGMII).

Resolve the issue by clearing "val" to 0 when writing to a new register.
After the fix, the register value is 0x2400.

Prior to the blamed commit, when the read-modify-write was open-coded,
the code saved the content of the DW_VR_MII_DIG_CTRL1 register in the
"ret" variable.

Fixes: ce8d6081fcf4 ("net: pcs: xpcs: add _modify() accessors")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
 drivers/net/pcs/pcs-xpcs.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/pcs/pcs-xpcs.c b/drivers/net/pcs/pcs-xpcs.c
index e270a75a988c..3de0a25a1eca 100644
--- a/drivers/net/pcs/pcs-xpcs.c
+++ b/drivers/net/pcs/pcs-xpcs.c
@@ -728,6 +728,7 @@ static int xpcs_config_aneg_c37_sgmii(struct dw_xpcs *xpcs,
 	if (ret < 0)
 		return ret;
 
+	val = 0;
 	mask = DW_VR_MII_DIG_CTRL1_MAC_AUTO_SW;
 	if (neg_mode == PHYLINK_PCS_NEG_INBAND_ENABLED)
 		val = DW_VR_MII_DIG_CTRL1_MAC_AUTO_SW;
-- 
2.34.1

[PATCH net 2/2] net: pcs: xpcs: actively unset DW_VR_MII_DIG_CTRL1_2G5_EN for 1G SGMII

[Vladimir Oltean]

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@nxp.com>
---
 drivers/net/pcs/pcs-xpcs.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/pcs/pcs-xpcs.c b/drivers/net/pcs/pcs-xpcs.c
index 3de0a25a1eca..2e2cc6153fdb 100644
--- a/drivers/net/pcs/pcs-xpcs.c
+++ b/drivers/net/pcs/pcs-xpcs.c
@@ -729,7 +729,8 @@ static int xpcs_config_aneg_c37_sgmii(struct dw_xpcs *xpcs,
 		return ret;
 
 	val = 0;
-	mask = DW_VR_MII_DIG_CTRL1_MAC_AUTO_SW;
+	mask = DW_VR_MII_DIG_CTRL1_2G5_EN | DW_VR_MII_DIG_CTRL1_MAC_AUTO_SW;
+
 	if (neg_mode == PHYLINK_PCS_NEG_INBAND_ENABLED)
 		val = DW_VR_MII_DIG_CTRL1_MAC_AUTO_SW;
 
-- 
2.34.1

Re: [PATCH net 1/2] net: pcs: xpcs: fix DW_VR_MII_DIG_CTRL1_2G5_EN bit being set for 1G SGMII w/o inband

[Maxime Chevallier]

Hello Vlad,

On Tue, 14 Jan 2025 18:47:20 +0200
Vladimir Oltean <vladimir.oltean@nxp.com> wrote:

> On a port with SGMII fixed-link at SPEED_1000, DW_VR_MII_DIG_CTRL1 gets
> set to 0x2404. This is incorrect, because bit 2 (DW_VR_MII_DIG_CTRL1_2G5_EN)
> is set.
> 
> It comes from the previous write to DW_VR_MII_AN_CTRL, because the "val"
> variable is reused and is dirty. Actually, its value is 0x4, aka
> FIELD_PREP(DW_VR_MII_PCS_MODE_MASK, DW_VR_MII_PCS_MODE_C37_SGMII).
> 
> Resolve the issue by clearing "val" to 0 when writing to a new register.
> After the fix, the register value is 0x2400.
> 
> Prior to the blamed commit, when the read-modify-write was open-coded,
> the code saved the content of the DW_VR_MII_DIG_CTRL1 register in the
> "ret" variable.
> 
> Fixes: ce8d6081fcf4 ("net: pcs: xpcs: add _modify() accessors")
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>

Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>

Thanks,

Maxime

Re: [PATCH net 2/2] net: pcs: xpcs: actively unset DW_VR_MII_DIG_CTRL1_2G5_EN for 1G SGMII

[Maxime Chevallier]

Hello Vlad,

On Tue, 14 Jan 2025 18:47:21 +0200
Vladimir Oltean <vladimir.oltean@nxp.com> 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@nxp.com>

Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>

Thanks,

Maxime

Re: [PATCH net 1/2] net: pcs: xpcs: fix DW_VR_MII_DIG_CTRL1_2G5_EN bit being set for 1G SGMII w/o inband

[Russell King (Oracle)]

On Tue, Jan 14, 2025 at 06:47:20PM +0200, Vladimir Oltean wrote:
> On a port with SGMII fixed-link at SPEED_1000, DW_VR_MII_DIG_CTRL1 gets
> set to 0x2404. This is incorrect, because bit 2 (DW_VR_MII_DIG_CTRL1_2G5_EN)
> is set.
> 
> It comes from the previous write to DW_VR_MII_AN_CTRL, because the "val"
> variable is reused and is dirty. Actually, its value is 0x4, aka
> FIELD_PREP(DW_VR_MII_PCS_MODE_MASK, DW_VR_MII_PCS_MODE_C37_SGMII).
> 
> Resolve the issue by clearing "val" to 0 when writing to a new register.
> After the fix, the register value is 0x2400.
> 
> Prior to the blamed commit, when the read-modify-write was open-coded,
> the code saved the content of the DW_VR_MII_DIG_CTRL1 register in the
> "ret" variable.
> 
> Fixes: ce8d6081fcf4 ("net: pcs: xpcs: add _modify() accessors")
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>

Good catch!

Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>

Thanks!

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

Re: [PATCH net 2/2] net: pcs: xpcs: actively unset DW_VR_MII_DIG_CTRL1_2G5_EN for 1G SGMII

[Russell King (Oracle)]

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@nxp.com>

Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.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.

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

Re: [PATCH net 2/2] net: pcs: xpcs: actively unset DW_VR_MII_DIG_CTRL1_2G5_EN for 1G SGMII

[Vladimir Oltean]

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@nxp.com>
> 
> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.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.

Re: [PATCH net 2/2] net: pcs: xpcs: actively unset DW_VR_MII_DIG_CTRL1_2G5_EN for 1G SGMII

[Russell King (Oracle)]

On Wed, Jan 15, 2025 at 04:51:45PM +0200, Vladimir Oltean wrote:
> 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@nxp.com>
> > 
> > Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.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.

No, I'm thinking that xpcs_config_aneg_c37_sgmii(),
xpcs_config_aneg_c37_1000basex() and xpcs_config_2500basex() can
be rolled into a single function.


	SGMII
	modify vendor 2 MII_BMCR
	- clear BMCR_ANENABLE
	modify vendor 2 DW_VR_MII_AN_CTRL
	- set DW_VR_MII_PCS_MODE_MASK to 
	  DW_VR_MII_PCS_MODE_C37_SGMII
	- configure  DW_VR_MII_TX_CONFIG_MASK for MAC or if txgbe, PHY side
	- set DW_VR_MII_AN_CTRL_8BIT (if txgbe)
	modify vendor 2 DW_VR_MII_DIG_CTRL1
	- set DW_VR_MII_DIG_CTRL1_MAC_AUTO_SW if
	    PHYLINK_PCS_NEG_INBAND_ENABLED
	- set DW_VR_MII_DIG_CTRL1_PHY_MODE_CTRL if txgbe
	write vendor 2 DW_VR_MII_DIG_CTRL1
	set BMCR_ANENABLE in vendor 2 MII_BMCR if
	  PHYLINK_PCS_NEG_INBAND_ENABLED

	1000BASE-X
	modify vendor 2 MII_BMCR
	- clear BMCR_ANENABLE
	modify DW_VR_MII_AN_CTRL
	- set DW_VR_MII_PCS_MODE_MASK to
	  DW_VR_MII_PCS_MODE_C37_1000BASEX
	- set DW_VR_MII_AN_INTR_EN if using interrupts (shouldn't SGMII
	  also do this?)
	encode advertisement and write to vendor 2 MII_ADVERTISE
	clear vendor 2 DW_VR_MII_AN_INTR_STS register (if using
	interrupts shouldn't this also apply to SGMII?)
	set BMCR_ANENABLE in vendor 2 MII_BMCR if
	  PHYLINK_PCS_NEG_INBAND_ENABLED

	2500BASE-X
	modify vendor 2 DW_VR_MII_DIG_CTRL1:
	- set DW_VR_MII_DIG_CTRL1_2G5_EN
	- clear DW_VR_MII_DIG_CTRL1_MAC_AUTO_SW
	modify vendor 2 MII_BMCR:
	- clear BMCR_ANENABLE, BMCR_SPEED100
	- set BMCR_SPEED1000
	(shouldn't this clear BMCR_ANENABLE first, like the other two
	 configurations above?)

So, sticking this altogether, making some assumptions on the above
questions, it becomes:

	modify vendor 2 MII_BMCR
	- clear BMCR_ANENABLE
	modify DW_VR_MII_AN_CTRL
	- set DW_VR_MII_PCS_MODE_MASK to 
	  - DW_VR_MII_PCS_MODE_C37_SGMII if using SGMII
	  - DW_VR_MII_PCS_MODE_C37_1000BASEX if using 1000BASE-X or
	    2500BASE-X
	- configure  DW_VR_MII_TX_CONFIG_MASK for MAC or if txgbe, PHY
	  side
	- set DW_VR_MII_AN_CTRL_8BIT (if txgbe)
	- set DW_VR_MII_AN_INTR_EN if using interrupts (shouldn't SGMII
	  also do this?)
	modify vendor 2 DW_VR_MII_DIG_CTRL1
	- set DW_VR_MII_DIG_CTRL1_MAC_AUTO_SW if
	    PHYLINK_PCS_NEG_INBAND_ENABLED
	- set DW_VR_MII_DIG_CTRL1_PHY_MODE_CTRL if txgbe
	encode advertisement and write to vendor 2 MII_ADVERTISE
	clear vendor 2 DW_VR_MII_AN_INTR_STS register
	set BMCR_ANENABLE in vendor 2 MII_BMCR if
	  PHYLINK_PCS_NEG_INBAND_ENABLED

Which would avoid variability in register values when phylink
transitions the PCS between SGMII, 1000base-X and 2500base-X that
will occur today - e.g., when switching from either SGMII or
1000base-X to 2500base-X, then the following register fields do
not get written and are left how they were last configured:

	DW_VR_MII_AN_CTRL at all
	DW_VR_MII_PCS_MODE_MASK
	DW_VR_MII_TX_CONFIG_MASK
	DW_VR_MII_AN_CTRL_8BIT
	DW_VR_MII_DIG_CTRL1_PHY_MODE_CTRL

For example, switching from SGMII to 2500base-X, the
DW_VR_MII_PCS_MODE_MASK field will be left as
DW_VR_MII_PCS_MODE_C37_SGMII, but if switching from 1000base-X to
2500base-X, it will be DW_VR_MII_PCS_MODE_C37_1000BASEX.

Maybe it doesn't matter, because maybe setting
DW_VR_MII_DIG_CTRL1_2G5_EN overrides a whole host of register
configuration?

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

Re: [PATCH net 1/2] net: pcs: xpcs: fix DW_VR_MII_DIG_CTRL1_2G5_EN bit being set for 1G SGMII w/o inband

[patchwork-bot+netdevbpf]

Hello:

This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Tue, 14 Jan 2025 18:47:20 +0200 you wrote:
> On a port with SGMII fixed-link at SPEED_1000, DW_VR_MII_DIG_CTRL1 gets
> set to 0x2404. This is incorrect, because bit 2 (DW_VR_MII_DIG_CTRL1_2G5_EN)
> is set.
> 
> It comes from the previous write to DW_VR_MII_AN_CTRL, because the "val"
> variable is reused and is dirty. Actually, its value is 0x4, aka
> FIELD_PREP(DW_VR_MII_PCS_MODE_MASK, DW_VR_MII_PCS_MODE_C37_SGMII).
> 
> [...]

Here is the summary with links:
  - [net,1/2] net: pcs: xpcs: fix DW_VR_MII_DIG_CTRL1_2G5_EN bit being set for 1G SGMII w/o inband
    https://git.kernel.org/netdev/net/c/5c71729ab92c
  - [net,2/2] net: pcs: xpcs: actively unset DW_VR_MII_DIG_CTRL1_2G5_EN for 1G SGMII
    https://git.kernel.org/netdev/net/c/d6e3316a1680

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html