| Message ID | 20250114164721.2879380-2-vladimir.oltean@nxp.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | d6e3316a1680305da291a5b5deaf424559aaf06c |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [net,1/2] net: pcs: xpcs: fix DW_VR_MII_DIG_CTRL1_2G5_EN bit being set for 1G SGMII w/o inband | expand |
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
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.
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.
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?
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;
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(-)