Netdev Archive on lore.kernel.org
 help / color / Atom feed
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Andre Przywara <andre.przywara@arm.com>
Cc: "David S . Miller" <davem@davemloft.net>,
	Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>,
	Robert Hancock <hancock@sedsystems.ca>,
	netdev@vger.kernel.org, Michal Simek <michal.simek@xilinx.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 07/14] net: axienet: Fix SGMII support
Date: Fri, 10 Jan 2020 18:05:46 +0000
Message-ID: <20200110180546.GK25745@shell.armlinux.org.uk> (raw)
In-Reply-To: <20200110173249.0b086a76@donnerap.cambridge.arm.com>

On Fri, Jan 10, 2020 at 05:32:49PM +0000, Andre Przywara wrote:
> On Fri, 10 Jan 2020 14:58:49 +0000
> Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:
> 
> > On Fri, Jan 10, 2020 at 11:54:08AM +0000, Andre Przywara wrote:
> > > With SGMII, the MAC and the PHY can negotiate the link speed between
> > > themselves, without the host needing to mediate between them.
> > > Linux recognises this, and will call phylink's mac_config with the speed
> > > member set to SPEED_UNKNOWN (-1).  
> > 
> > I wonder whether you have read the documentation for the phylink
> > mac_config() method (if not, please read it, it contains some very
> > important information about what mac_config() should do.)  When
> > operating in SGMII in-band mode, state->speed and state->duplex are
> > not actually valid.
> > 
> > You'll probably want to submit a better patch after reading the
> > documentation.
> 
> Sure, I am admittedly quite clueless about phylink in particular, and found the available information quite daunting.
> So I tried my best in looking at what other drivers do. From what I got there is that you speed=-1 should be ignored, but the other fields still handled.
> Also I was somewhat puzzled, as I was expecting "mode" being MLO_AN_INBAND. But in fact it's called twice with MLO_AN_PHY, and mac_pcs_get_state() never gets called:

Okay.  When phylink is in PHY mode, it operates just the same as the
more conventional phylib setup: phylib reports the negotiation results
to the network driver which sets the MAC up appropriately.

The only difference between the phylib way of doing things and phylink
is that phylink is in the path, so mac_config() gets called to setup
the MAC with the results of the PHY negotiation.  This will be the case
irrespective of which PHY interface mode is being used.

So, in PHY mode, we don't care whether there is in-band signalling or
not - and the reason that's vague is because it _is_ already vague
with existing phylib setups using SGMII.

So, basically, the MLO_AN_PHY mode is the complete equivalent of
phylib without phylink.


MLO_AN_FIXED is just like MLO_AN_PHY, except phylink is operating in
fixed-link mode - similar to the old fixed-link emulated PHY setup that
phylib offered, but without needing a MII bus and squeezing the
information through phylib's interfaces.  From the point of view of a
MAC driver, however, it's just the same as MLO_AN_PHY.


If you configure phylink for inband mode by placing

	managed = "in-band-status";

in DT, then phylink will operate in MLO_AN_INBAND mode.  It will also
operate in that mode if the MAC is connected directly to a SFP cage
and a SFP is inserted that requires inband mode.

Exactly how inband mode operates depends in the nature of the inband
signalling.  There's two different schemes:

SGMII: the PHY communicates the speed and duplex settings to the MAC
PCS through the in-band control word.  Pause mode is not available
via the in-band control word.  SGMII can operate at 10M, 100M or 1G,
half or full duplex.  The PHY may or may not be accessible.

Here, phylink will read the speed and duplex from the MAC PCS rather
than the PHY, and if the PHY is accessible, phylink will merge the
negotiated pause mode information and pass this over to the MAC.

(Note: there are some vendor extensions to pass pause mode through
SGMII as well, but I haven't seen a MAC that supports them yet.)

1000BASE-X (aka 802.3z): the link partner advertises its capabilities
via the in-band control word, which are:
	- full duplex
	- half duplex
	- pause
	- asym pause

and each end of the link has to resolve the capabilities to agree the
operating mode of the link.  As only a single speed is supported in
this mode, there is no need to advertise any speed capabilities (if
the link operates at dis-similar speeds - for example, 2500BASE-X at
one end and 1000BASE-X on the other, there's no way to get the control
word through.)

Here, phylink will only read from the MAC PCS to discover the results
of the negotiation; there will be no call to mac_config().


Phylink currently expects the result of the in-band negotiation at
the MAC PCS to be propagated to the MAC by hardware (as this is what
happens with mvneta and mvpp2, the first two MACs that phylink
supports.)  If there is hardware that requires something else, then
that will need to be revisited, and will result in not only code but
also documentation updates as well.

I hope this helps you to understand phylink.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

  reply index

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-10 11:54 [PATCH 00/14] net: axienet: Error handling, SGMII and 64-bit DMA fixes Andre Przywara
2020-01-10 11:54 ` [PATCH 01/14] net: xilinx: temac: Relax Kconfig dependencies Andre Przywara
2020-01-10 14:19   ` Radhey Shyam Pandey
2020-01-10 11:54 ` [PATCH 02/14] net: axienet: Propagate failure of DMA descriptor setup Andre Przywara
2020-01-10 14:54   ` Radhey Shyam Pandey
2020-01-10 17:53     ` Radhey Shyam Pandey
2020-01-10 11:54 ` [PATCH 03/14] net: axienet: Fix DMA descriptor cleanup path Andre Przywara
2020-01-10 15:14   ` Radhey Shyam Pandey
2020-01-10 15:43     ` Andre Przywara
2020-01-10 17:05       ` Radhey Shyam Pandey
2020-01-16 18:03         ` Andre Przywara
2020-01-20 18:32           ` Radhey Shyam Pandey
2020-01-10 11:54 ` [PATCH 04/14] net: axienet: Improve DMA error handling Andre Przywara
2020-01-10 15:26   ` Radhey Shyam Pandey
2020-01-10 11:54 ` [PATCH 05/14] net: axienet: Factor out TX descriptor chain cleanup Andre Przywara
2020-01-10 18:04   ` Radhey Shyam Pandey
2020-01-10 11:54 ` [PATCH 06/14] net: axienet: Check for DMA mapping errors Andre Przywara
2020-01-13  5:54   ` Radhey Shyam Pandey
2020-01-10 11:54 ` [PATCH 07/14] net: axienet: Fix SGMII support Andre Przywara
2020-01-10 14:04   ` Andrew Lunn
2020-01-10 14:20     ` Andre Przywara
2020-01-10 14:26       ` Andrew Lunn
2020-01-10 15:04       ` Russell King - ARM Linux admin
2020-01-10 15:22         ` Russell King - ARM Linux admin
2020-01-10 17:04           ` Russell King - ARM Linux admin
2020-01-18 11:22             ` Russell King - ARM Linux admin
2020-01-20 14:50               ` Andre Przywara
2020-01-20 15:45                 ` Russell King - ARM Linux admin
2020-01-27 17:04                   ` Andre Przywara
2020-01-27 17:20                     ` Radhey Shyam Pandey
2020-01-27 18:53                     ` Russell King - ARM Linux admin
2020-04-22  1:45                       ` Xilinx axienet 1000BaseX support (was: Re: [PATCH 07/14] net: axienet: Fix SGMII support) Robert Hancock
2020-04-22  7:51                         ` Russell King - ARM Linux admin
2020-04-22 16:31                           ` Xilinx axienet 1000BaseX support Robert Hancock
2020-04-28 21:59                           ` Robert Hancock
2020-04-28 23:01                             ` Russell King - ARM Linux admin
2020-04-28 23:51                               ` Robert Hancock
2020-04-29  8:21                                 ` Russell King - ARM Linux admin
2020-01-10 14:58   ` [PATCH 07/14] net: axienet: Fix SGMII support Russell King - ARM Linux admin
2020-01-10 17:32     ` Andre Przywara
2020-01-10 18:05       ` Russell King - ARM Linux admin [this message]
2020-01-10 19:33         ` Andrew Lunn
2020-01-10 11:54 ` [PATCH 08/14] net: axienet: Drop MDIO interrupt registers from ethtools dump Andre Przywara
2020-01-13  6:02   ` Radhey Shyam Pandey
2020-01-10 11:54 ` [PATCH 09/14] net: axienet: Add mii-tool support Andre Przywara
2020-01-13  6:12   ` Radhey Shyam Pandey
2020-03-12 11:41     ` Andre Przywara
2020-01-10 11:54 ` [PATCH 10/14] net: axienet: Wrap DMA pointer writes to prepare for 64 bit Andre Przywara
2020-01-10 11:54 ` [PATCH 11/14] net: axienet: Upgrade descriptors to hold 64-bit addresses Andre Przywara
2020-01-14 16:35   ` Radhey Shyam Pandey
2020-01-14 17:29     ` Andre Przywara
2020-01-10 11:54 ` [PATCH 12/14] net: axienet: Autodetect 64-bit DMA capability Andre Przywara
2020-01-10 14:08   ` Andrew Lunn
2020-01-10 14:13     ` Andre Przywara
2020-01-10 14:22       ` Andrew Lunn
2020-01-10 15:08         ` Andre Przywara
2020-01-10 15:22           ` Andrew Lunn
2020-01-14 17:03   ` Radhey Shyam Pandey
2020-01-14 17:41     ` Andre Przywara
2020-01-15  6:02       ` Radhey Shyam Pandey
2020-01-10 11:54 ` [PATCH 13/14] net: axienet: Allow DMA to beyond 4GB Andre Przywara
2020-01-10 11:54 ` [PATCH 14/14] net: axienet: Update devicetree binding documentation Andre Przywara
2020-01-21 21:51   ` Rob Herring
2020-01-24 16:29     ` Andre Przywara
2020-01-27  9:28       ` Radhey Shyam Pandey

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=20200110180546.GK25745@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=andre.przywara@arm.com \
    --cc=davem@davemloft.net \
    --cc=hancock@sedsystems.ca \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michal.simek@xilinx.com \
    --cc=netdev@vger.kernel.org \
    --cc=radhey.shyam.pandey@xilinx.com \
    /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

Netdev Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/netdev/0 netdev/git/0.git
	git clone --mirror https://lore.kernel.org/netdev/1 netdev/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 netdev netdev/ https://lore.kernel.org/netdev \
		netdev@vger.kernel.org
	public-inbox-index netdev

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.netdev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git