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
next prev parent reply other threads:[~2020-03-20 9:55 UTC|newest]
Thread overview: 30+ 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:21 ` Russell King - ARM Linux admin
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 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 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).