All of lore.kernel.org
 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] net: phy: marvell10g: support XFI rate matching mode
Date: Thu, 25 Jun 2020 18:50:12 +0100	[thread overview]
Message-ID: <20200625175012.GL1551@shell.armlinux.org.uk> (raw)
In-Reply-To: <79ca4ba3129a92e20943516b4af0dca510e938b3.1593105561.git.baruch@tkos.co.il>

On Thu, Jun 25, 2020 at 08:19:21PM +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.

Rate matching brings with it a whole host of issues, not just the
interface type, but also the phydev->speed, which is commonly used
to program the MAC.

Rate matching is also used with the unsupported 3310 PHY on the ZII
devel rev C board, and there we need the PHY to also report a speed
of 10G as well as the interface type correctly.  The whole thing
gets quite yucky when you have a 10baseT link on a 3310 PHY with
the host interface running with 10GBASE-R but the MAC programmed for
10Mbps.

The approach I hacked up was to split the current link_state into
media_state and mac_state, and then do this:

+       /* If the PHY supports rate-matching, it will report slower speeds
+        * for these fixed-speed interface modes. Force the MAC side to
+        * full speed.
+        */
+       if (mac_state.interface == PHY_INTERFACE_MODE_XAUI ||
+           mac_state.interface == PHY_INTERFACE_MODE_RXAUI ||
+           mac_state.interface == PHY_INTERFACE_MODE_10GBASER) {
+               mac_state.speed = SPEED_10000;
+               mac_state.duplex = DUPLEX_FULL;
+       }

which is really a dirty hack.  I'd need to re-read the switch
documentation and review what we're doing to check whether such a
thing is really necessary, or whether merely using 10GBASE-R but
programming the MAC to 10Mbps (e.g.) is actually acceptable.

What I'm basically saying is, there could be way more to this than
just setting the interface mode.

We also /should/ be setting the 3310's interface mode according to
how the PHY is configured - but that is slightly complicated by the
various different modes presented by different variants of the PHY
(the P variant vs the non-P variant.)  I seem to remember that
disambiguating them requires looking at the revision bits in the
PHY ID registers, and I've been debating whether we should not be
using the standard mask when matching them.

-- 
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-25 17:50 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-25 17:19 [PATCH] net: phy: marvell10g: support XFI rate matching mode Baruch Siach
2020-06-25 17:50 ` Russell King - ARM Linux admin [this message]
2020-06-25 21:32   ` Russell King - ARM Linux admin

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=20200625175012.GL1551@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 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.