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