All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jose Abreu <Jose.Abreu@synopsys.com>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: Andrew Lunn <andrew@lunn.ch>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: RE: [RFC net-next 2/5] net: phylink: add separate pcs operations structure
Date: Fri, 20 Mar 2020 09:55:12 +0000	[thread overview]
Message-ID: <BN8PR12MB32666C9584E54DE2A7FDAD05D3F50@BN8PR12MB3266.namprd12.prod.outlook.com> (raw)
In-Reply-To: <20200319111425.GC25745@shell.armlinux.org.uk>

From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Date: Mar/19/2020, 11:14:25 (UTC+00:00)

> On Wed, Mar 18, 2020 at 07:45:52AM +0000, Jose Abreu wrote:
> > From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
> > Date: Mar/17/2020, 16:52:08 (UTC+00:00)
> > 
> > > On Tue, Mar 17, 2020 at 04:04:28PM +0000, Jose Abreu wrote:
> > > > From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
> > > > Date: Mar/17/2020, 15:56:10 (UTC+00:00)
> > > > 
> > > > > > Please consider removing this condition and just rely on an_enabled field. 
> > > > > > I have USXGMII support for Clause 73 Autoneg so this won't work with 
> > > > > > that.
> > > 
> > > Do you really mean USXGMII or XLGMII that you recently contributed?
> > > XLGMII makes more sense for clause 73.
> > > 
> > > > > That is actually incorrect.  SGMII can have an_enabled being true, but
> > > > > SGMII is not an autonegotiation between the MAC and PHY - it is merely
> > > > > a mechanism for the PHY to inform the MAC what the results of _its_
> > > > > negotiation are.
> > > > > 
> > > > > I suspect USXGMII is the same since it is just an "upgraded" version of
> > > > > SGMII.  Please can you check whether there really is any value in trying
> > > > > (and likely failing) to restart the "handshake" with the PHY from the
> > > > > MAC end, rather than requesting the PHY to restart negotiation on its
> > > > > media side.
> > > > 
> > > > I think we are speaking of different things here. I'm speaking about 
> > > > end-to-end Autoneg. Not PHY <-> PCS <-> MAC.
> > > 
> > > What do you mean end-to-end autoneg?  Let's take a simple example for
> > > SGMII, here is the complete setup:
> > > 
> > > MAC <--> PCS <--SGMII--> PHY <--MEDIA--> PHY <--SGMII--> MAC
> > > 
> > > Generally, asking the PCS to "renegotiate" will either be ignored, or
> > > might cause the PCS to restart the handshake with the PHY depending on
> > > the implementation.  It will not cause the PHY to renegotiate with the
> > > remote PHY.
> > > 
> > > Asking the PHY to renegotiate will cause the link to drop, which
> > > updates the config_reg word sent to the PCS to indicate link down.
> > > When the link is re-established, the config_reg word is updated again
> > > with the new link parameters and that sent to the PCS.
> > > 
> > > So, just because something is closer to the MAC does not necessarily
> > > mean that it causes more of the blocks to "renegotiate" when asked to
> > > do so.
> > > 
> > > In SGMII, the PHY is the "master" and this is what needs negotiation
> > > restarted on "ethtool -r" to have the effect that the user desires.
> > > 
> > > I believe (but I don't know for certain, because the USXGMII
> > > documentation is not available to me) that USXGMII is SGMII extended
> > > up to additionally include 10G, 5G and 2.5G speeds, and otherwise is
> > > basically the same mechanism.
> > > 
> > > So, I would suggest that USXGMII and SGMII should be treated the same,
> > > and for both of them, a renegotiation should always be performed at
> > > the PHY and not the PCS.
> > > 
> > > There is another reason not to try triggering renegotiation at both
> > > the PHY and PCS.  When the PHY is renegotiating, the state machines
> > > at both the PHY and PCS end are in the process of changing - if we
> > > hit the PCS with a request to renegotiate, and the hardware isn't
> > > setup to ignore it, that could occur in an unexpected state - the risk
> > > of triggering a hardware problem could be higher.
> > > 
> > > So, based on this, I don't think it's a good idea to restart
> > > negotiation at the PCS for SGMII and USXGMII modes.
> > > 
> > > For the 802.3z based protocols, it makes complete sense to do so,
> > > because the PCS are the blocks involved in the actual media negotiation
> > > and there is no place else to restart negotiation:
> > > 
> > > MAC <---> PCS <----fiber 1000base-X----> PCS <---> MAC
> > 
> > That's kind of the setup I have, hence the need for me to restart ... I 
> > have this:
> > 
> > MAC <-> PCS <-> SERDES <-> Copper <-> SERDES <-> PCS <-> MAC
> > 
> > So, no PHY to restart Autoneg.
> 
> And the protocol over the copper is USXGMII?

No, I don't think so. I can check with HW team but I think its 10GKR (not 
sure though).

---
Thanks,
Jose Miguel Abreu

  reply	other threads:[~2020-03-20  9:55 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-17 14:49 [RFC net-next 0/2] split phylink PCS operations and add PCS support for dpaa2 Russell King - ARM Linux admin
2020-03-17 14:52 ` [RFC net-next 1/5] net: phylink: rename 'ops' to 'mac_ops' Russell King
2020-03-17 16:20   ` Andrew Lunn
2020-03-17 14:52 ` [RFC net-next 2/5] net: phylink: add separate pcs operations structure Russell King
2020-03-17 15:48   ` Jose Abreu
2020-03-17 15:56     ` Russell King - ARM Linux admin
2020-03-17 16:04       ` Jose Abreu
2020-03-17 16:52         ` Russell King - ARM Linux admin
2020-03-18  7:45           ` Jose Abreu
2020-03-19 11:14             ` Russell King - ARM Linux admin
2020-03-20  9:55               ` Jose Abreu [this message]
2020-03-17 16:38   ` Andrew Lunn
2020-03-17 16:54     ` Russell King - ARM Linux admin
2020-03-19 12:14       ` Russell King - ARM Linux admin
2020-03-19 15:06         ` Andrew Lunn
2020-03-19 17:20           ` Russell King - ARM Linux admin
2020-03-19 20:59           ` Russell King - ARM Linux admin
2020-03-24 19:46           ` Russell King - ARM Linux admin
2020-03-17 14:52 ` [RFC net-next 3/5] arm64: dts: lx2160a: add PCS MDIO nodes Russell King
2020-03-26 21:14   ` Ioana Ciornei
2020-03-26 21:14     ` Ioana Ciornei
2020-03-26 21:21     ` Russell King - ARM Linux admin
2020-03-26 21:21       ` Russell King - ARM Linux admin
2020-03-26 21:26       ` Ioana Ciornei
2020-03-26 21:26         ` Ioana Ciornei
2020-03-17 14:53 ` [RFC net-next 4/5] dpaa2-mac: add 1000BASE-X/SGMII PCS support Russell King
2020-03-26 22:09   ` Ioana Ciornei
2020-03-17 14:53 ` [RFC net-next 5/5] dpaa2-mac: add 10GBASE-R " Russell King
2020-03-26 14:57 ` [RFC net-next 0/2] split phylink PCS operations and add PCS support for dpaa2 Russell King - ARM Linux admin
2020-03-26 14:57   ` Russell King - ARM Linux admin
2020-03-26 15:04   ` Andrew Lunn
2020-03-26 15:04     ` Andrew Lunn
2020-03-26 15:14 ` [PATCH " Russell King - ARM Linux admin
2020-03-30  4:57   ` David Miller
2020-03-30  8:44     ` 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=BN8PR12MB32666C9584E54DE2A7FDAD05D3F50@BN8PR12MB3266.namprd12.prod.outlook.com \
    --to=jose.abreu@synopsys.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    /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.