netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Baruch Siach <baruch@tkos.co.il>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
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: Wed, 01 Jul 2020 10:23:12 +0300	[thread overview]
Message-ID: <87v9j7em1r.fsf@tarshish> (raw)
In-Reply-To: <20200629092224.GS1551@shell.armlinux.org.uk>

Hi Russell,

On Mon, Jun 29 2020, Russell King - ARM Linux admin wrote:
> 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.

Thanks for you review.

> 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.

Flow control is disabled anyway in my use case (vpp).

> 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?

How does the switch discover the media side speed? Is there some sort of
in-band information exchange?

> 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?

I will keep that in mind when stress testing the network. We might need
a way to set IPG on the MAC side if the MAC supports that (mvpp2 in this
case).

baruch

>>  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
>> 
>> 


-- 
                                                     ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

  reply	other threads:[~2020-07-01  7:23 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
2020-07-01  7:23   ` Baruch Siach [this message]
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=87v9j7em1r.fsf@tarshish \
    --to=baruch@tkos.co.il \
    --cc=andrew@lunn.ch \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=linux@armlinux.org.uk \
    --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).