netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Baruch Siach <baruch@tkos.co.il>
Cc: netdev@vger.kernel.org, Andrew Lunn <andrew@lunn.ch>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Shmuel Hazan <sh@tkos.co.il>
Subject: Re: [PATCH v2] net: phy: marvell10g: support XFI rate matching mode
Date: Mon, 29 Jun 2020 10:22:24 +0100	[thread overview]
Message-ID: <20200629092224.GS1551@shell.armlinux.org.uk> (raw)
In-Reply-To: <76ee08645fd35182911fd2bac2546e455c4b662c.1593327891.git.baruch@tkos.co.il>

On Sun, Jun 28, 2020 at 10:04:51AM +0300, Baruch Siach wrote:
> When the hardware MACTYPE hardware configuration pins are set to "XFI
> with Rate Matching" the PHY interface operate at fixed 10Gbps speed. The
> MAC buffer packets in both directions to match various wire speeds.
> 
> Read the MAC Type field in the Port Control register, and set the MAC
> interface speed accordingly.
> 
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> ---
> v2: Move rate matching state read to config_init (RMK)

Not quite what I was after, but it'll do for now.

My only system which has a 3310 PHY and is configured for rate matching
(using an XAUI interface, mode 1) seems to be sick - the 3310 no longer
correctly negotiates on the media side (will only link at 100M/Half and
only passes traffic in one direction), which makes any development with
it rather difficult.  Either the media side drivers have failed or the
magnetics.

I was also hoping for some discussion, as I bought up a few points
about the 3310's rate matching - unless you have the version with
MACsec, the PHY expects the host side to rate limit the egress rate to
the media rate and will _not_ send pause frames.  If you have MACsec,
and the MACsec hardware is enabled (although may not be encrypting),
then the PHY will send pause frames to the host as the internal buffer
fills.

Then there's the whole question of what phydev->speed etc should be set
to - the media speed or the host side link speed with the PHY, and then
how the host side should configure itself.  At least the 88E6390x
switch will force itself to the media side speed using that while in
XAUI mode, resulting in a non-functioning speed.  So should the host
side force itself to 10G whenever in something like XAUI mode?

What do we do about the egress rate - ignore that statement and hope
that the 3310 doesn't create bad packets on the wire if we fill up its
internal buffer?

> ---
>  drivers/net/phy/marvell10g.c | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
> index d4c2e62b2439..a7610eb55f30 100644
> --- a/drivers/net/phy/marvell10g.c
> +++ b/drivers/net/phy/marvell10g.c
> @@ -80,6 +80,8 @@ enum {
>  	MV_V2_PORT_CTRL		= 0xf001,
>  	MV_V2_PORT_CTRL_SWRST	= BIT(15),
>  	MV_V2_PORT_CTRL_PWRDOWN = BIT(11),
> +	MV_V2_PORT_MAC_TYPE_MASK = 0x7,
> +	MV_V2_PORT_MAC_TYPE_RATE_MATCH = 0x6,
>  	/* Temperature control/read registers (88X3310 only) */
>  	MV_V2_TEMP_CTRL		= 0xf08a,
>  	MV_V2_TEMP_CTRL_MASK	= 0xc000,
> @@ -91,6 +93,7 @@ enum {
>  
>  struct mv3310_priv {
>  	u32 firmware_ver;
> +	bool rate_match;
>  
>  	struct device *hwmon_dev;
>  	char *hwmon_name;
> @@ -458,7 +461,9 @@ static bool mv3310_has_pma_ngbaset_quirk(struct phy_device *phydev)
>  
>  static int mv3310_config_init(struct phy_device *phydev)
>  {
> +	struct mv3310_priv *priv = dev_get_drvdata(&phydev->mdio.dev);
>  	int err;
> +	int val;
>  
>  	/* Check that the PHY interface type is compatible */
>  	if (phydev->interface != PHY_INTERFACE_MODE_SGMII &&
> @@ -475,6 +480,12 @@ static int mv3310_config_init(struct phy_device *phydev)
>  	if (err)
>  		return err;
>  
> +	val = phy_read_mmd(phydev, MDIO_MMD_VEND2, MV_V2_PORT_CTRL);
> +	if (val < 0)
> +		return val;
> +	priv->rate_match = ((val & MV_V2_PORT_MAC_TYPE_MASK) ==
> +			MV_V2_PORT_MAC_TYPE_RATE_MATCH);
> +
>  	/* Enable EDPD mode - saving 600mW */
>  	return mv3310_set_edpd(phydev, ETHTOOL_PHY_EDPD_DFLT_TX_MSECS);
>  }
> @@ -581,6 +592,17 @@ static int mv3310_aneg_done(struct phy_device *phydev)
>  
>  static void mv3310_update_interface(struct phy_device *phydev)
>  {
> +	struct mv3310_priv *priv = dev_get_drvdata(&phydev->mdio.dev);
> +
> +	/* In "XFI with Rate Matching" mode the PHY interface is fixed at
> +	 * 10Gb. The PHY adapts the rate to actual wire speed with help of
> +	 * internal 16KB buffer.
> +	 */
> +	if (priv->rate_match) {
> +		phydev->interface = PHY_INTERFACE_MODE_10GBASER;
> +		return;
> +	}
> +
>  	if ((phydev->interface == PHY_INTERFACE_MODE_SGMII ||
>  	     phydev->interface == PHY_INTERFACE_MODE_2500BASEX ||
>  	     phydev->interface == PHY_INTERFACE_MODE_10GBASER) &&
> -- 
> 2.27.0
> 
> 

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

  reply	other threads:[~2020-06-29 20:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-28  7:04 [PATCH v2] net: phy: marvell10g: support XFI rate matching mode Baruch Siach
2020-06-29  9:22 ` Russell King - ARM Linux admin [this message]
2020-07-01  7:23   ` Baruch Siach
2020-07-01  9:06     ` Russell King - ARM Linux admin
2020-06-30  0:25 ` David Miller

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=20200629092224.GS1551@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=andrew@lunn.ch \
    --cc=baruch@tkos.co.il \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=sh@tkos.co.il \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).