All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wong Vee Khee <vee.khee.wong@linux.intel.com>
To: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
	Jose Abreu <Jose.Abreu@synopsys.com>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	"David S . Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Wong Vee Khee <veekhee@gmail.com>
Subject: Re: [PATCH net-next 2/2] net: pcs: xpcs: fix incorrect CL37 AN sequence
Date: Wed, 29 Sep 2021 19:45:22 +0800	[thread overview]
Message-ID: <20210929114522.GA2089@linux.intel.com> (raw)
In-Reply-To: <20210928102730.72vays22sulixodb@skbuf>

On Tue, Sep 28, 2021 at 10:27:31AM +0000, Vladimir Oltean wrote:
> On Tue, Sep 28, 2021 at 12:19:38PM +0800, Wong Vee Khee wrote:
> > According to Synopsys DesignWare Cores Ethernet PCS databook, it is
> > required to disable Clause 37 auto-negotiation by programming bit-12
> > (AN_ENABLE) to 0 if it is already enabled, before programming various
> > fields of VR_MII_AN_CTRL registers.
> > 
> > After all these programming are done, it is then required to enable
> > Clause 37 auto-negotiation by programming bit-12 (AN_ENABLE) to 1.
> > 
> > Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
> > Signed-off-by: Wong Vee Khee <vee.khee.wong@linux.intel.com>
> > ---
> 
> 
> 
> >  drivers/net/pcs/pcs-xpcs.c | 24 ++++++++++++++++++++----
> >  1 file changed, 20 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/net/pcs/pcs-xpcs.c b/drivers/net/pcs/pcs-xpcs.c
> > index da8c81d25edd..eacfb32bb229 100644
> > --- a/drivers/net/pcs/pcs-xpcs.c
> > +++ b/drivers/net/pcs/pcs-xpcs.c
> > @@ -709,11 +709,14 @@ static int xpcs_config_aneg_c37_sgmii(struct dw_xpcs *xpcs, unsigned int mode)
> >  	int ret;
> >  
> >  	/* For AN for C37 SGMII mode, the settings are :-
> > -	 * 1) VR_MII_AN_CTRL Bit(2:1)[PCS_MODE] = 10b (SGMII AN)
> > -	 * 2) VR_MII_AN_CTRL Bit(3) [TX_CONFIG] = 0b (MAC side SGMII)
> > +	 * 1) VR_MII_MMD_CTRL Bit(12) [AN_ENABLE] = 0b (Disable SGMII AN in case
> > +	      it is already enabled)
> > +	 * 2) VR_MII_AN_CTRL Bit(2:1)[PCS_MODE] = 10b (SGMII AN)
> > +	 * 3) VR_MII_AN_CTRL Bit(3) [TX_CONFIG] = 0b (MAC side SGMII)
> >  	 *    DW xPCS used with DW EQoS MAC is always MAC side SGMII.
> > -	 * 3) VR_MII_DIG_CTRL1 Bit(9) [MAC_AUTO_SW] = 1b (Automatic
> > +	 * 4) VR_MII_DIG_CTRL1 Bit(9) [MAC_AUTO_SW] = 1b (Automatic
> >  	 *    speed/duplex mode change by HW after SGMII AN complete)
> > +	 * 5) VR_MII_MMD_CTRL Bit(12) [AN_ENABLE] = 1b (Enable SGMII AN)
> >  	 *
> >  	 * Note: Since it is MAC side SGMII, there is no need to set
> >  	 *	 SR_MII_AN_ADV. MAC side SGMII receives AN Tx Config from
> > @@ -721,6 +724,11 @@ static int xpcs_config_aneg_c37_sgmii(struct dw_xpcs *xpcs, unsigned int mode)
> >  	 *	 between PHY and Link Partner. There is also no need to
> >  	 *	 trigger AN restart for MAC-side SGMII.
> >  	 */
> > +	ret = xpcs_modify(xpcs, MDIO_MMD_VEND2, DW_VR_MII_MMD_CTRL, AN_CL37_EN,
> 
> Would you mind using "MDIO_CTRL1" instead of "DW_VR_MII_MMD_CTRL", and
> "MDIO_AN_CTRL1_ENABLE" instead of "AN_CL37_EN"? After all, the
> "SR_MII_CTRL" naming from the data book comes from "Standard Register".
> 
> > +			  0);
> > +	if (ret < 0)
> > +		return ret;
> > +
> >  	ret = xpcs_read(xpcs, MDIO_MMD_VEND2, DW_VR_MII_AN_CTRL);
> >  	if (ret < 0)
> >  		return ret;
> > @@ -745,7 +753,15 @@ static int xpcs_config_aneg_c37_sgmii(struct dw_xpcs *xpcs, unsigned int mode)
> >  	else
> >  		ret &= ~DW_VR_MII_DIG_CTRL1_MAC_AUTO_SW;
> >  
> > -	return xpcs_write(xpcs, MDIO_MMD_VEND2, DW_VR_MII_DIG_CTRL1, ret);
> > +	ret = xpcs_write(xpcs, MDIO_MMD_VEND2, DW_VR_MII_DIG_CTRL1, ret);
> 
> There is an interesting note in the data book about the MAC_AUTO_SW bit:
> 
> | This mode is valid only when DWC_xpcs is configured as MAC-side
> | SGMII/USXGMII/QSGMII and should be set only when Auto-negotiation is
> | enabled (AN_ENABLE bit is set to 1).
> 
> With your patch, it will be set while the AN_ENABLE bit is zero.
> I wonder whether that's a poor choice of words, because it does
> contradict with the sequence described in section "7.12.1 SGMII
> Auto-Negotiation", and if it just means "only set MAC_AUTO_SW if you
> intend to eventually set AN_ENABLE", not "you must set it only _while_
> AN_ENABLE is set".
>

I am actually following what is described in section "7.12.1 SGMII
Auto-Negotiation". I guess it is more accurate to follow what is
described in there.
 
> > +	if (ret < 0)
> > +		return ret;
> > +
> > +	ret = xpcs_read(xpcs, MDIO_MMD_VEND2, DW_VR_MII_MMD_CTRL);
> > +	if (ret < 0)
> > +		return ret;
> > +	ret |= AN_CL37_EN;
> 
> So this is the part that really confuses me.
> The xpcs driver did not use to do any configuration at all for this bit.
> Am I right in assuming that we were all operating with the default value?
> Because in your case, the default value is set by your bootloader
> (AN_CL37_EN is set), and in my case, the default is the hardware reset
> (AN_CL37_EN is not set). I think (haven't tested) that this change would
> actually break my setups where phylink_autoneg_inband(mode) returns false.
> 
> So could you please add this conditional?
> 
> 	if (phylink_autoneg_inband(mode))
> 		ret |= MDIO_AN_CTRL1_ENABLE;
> 	else
> 		ret &= ~MDIO_AN_CTRL1_ENABLE;
>

Added this. I will still use 'AN_CL37_EN' instead of
'MDIO_AN_CTRL1_ENABLE' for now. Let's rename all 'AN_CL37_EN' to
'MDIO_AN_CTRL1_ENABLE' later on net-next.

> > +	return xpcs_write(xpcs, MDIO_MMD_VEND2, DW_VR_MII_MMD_CTRL, ret);
> >  }
> >  
> >  static int xpcs_config_2500basex(struct dw_xpcs *xpcs)
> > -- 
> > 2.25.1
> > 

  reply	other threads:[~2021-09-29 11:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-28  4:19 [PATCH net-next 1/2] net: pcs: xpcs: introduce xpcs_modify() helper function Wong Vee Khee
2021-09-28  4:19 ` Wong Vee Khee
2021-09-28  4:19 ` [PATCH net-next 2/2] net: pcs: xpcs: fix incorrect CL37 AN sequence Wong Vee Khee
2021-09-28 10:27   ` Vladimir Oltean
2021-09-29 11:45     ` Wong Vee Khee [this message]
2021-09-28 10:41   ` Vladimir Oltean
2021-09-29 11:46     ` Wong Vee Khee

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210929114522.GA2089@linux.intel.com \
    --to=vee.khee.wong@linux.intel.com \
    --cc=Jose.Abreu@synopsys.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=veekhee@gmail.com \
    --cc=vladimir.oltean@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.