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 -
next prev parent 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 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.