From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org, andrew@lunn.ch,
f.fainelli@gmail.com, vivien.didelot@gmail.com,
claudiu.manoil@nxp.com, alexandru.marginean@nxp.com,
ioana.ciornei@nxp.com
Subject: Re: [PATCH v2 net-next 5/6] net: dsa: felix: delete .phylink_mac_an_restart code
Date: Sat, 4 Jul 2020 15:56:14 +0100 [thread overview]
Message-ID: <20200704145613.GR1551@shell.armlinux.org.uk> (raw)
In-Reply-To: <20200704124507.3336497-6-olteanv@gmail.com>
On Sat, Jul 04, 2020 at 03:45:06PM +0300, Vladimir Oltean wrote:
> From: Vladimir Oltean <vladimir.oltean@nxp.com>
>
> The Cisco SGMII and USXGMII standards specify control information
> exchange to be "achieved by using the Auto-Negotiation functionality
> defined in Clause 37 of the IEEE Specification 802.3z".
>
> The differences to clause 37 auto-negotiation are specified by the
> respective standards. In the case of SGMII, the differences are spelled
> out as being:
>
> - A reduction of the link timer value, from 10 ms to 1.6 ms.
> - A customization of the tx_config_reg[15:0], mostly to allow
> propagation of speed information.
>
> A similar situation is going on for USXGMII as well: "USXGMII Auto-neg
> mechanism is based on Clause 37 (Figure 37-6) plus additional management
> control to select USXGMII mode".
>
> The point is, both Cisco standards make explicit reference that they
> require an auto-negotiation state machine implemented as per "Figure
> 37-6-Auto-Negotiation state diagram" from IEEE 802.3. In the SGMII spec,
> it is very clearly pointed out that both the MAC PCS (Figure 3 MAC
> Functional Block) and the PHY PCS (Figure 2 PHY Functional Block)
> contain an auto-negotiation block defined by "Auto-Negotiation Figure
> 37-6".
>
> Since both ends of the SGMII/USXGMII link implement the same state
> machine (just carry different tx_config_reg payloads, which they convey
> to their link partner via /C/ ordered sets), naturally the ability to
> restart auto-negotiation is symmetrical. The state machine in IEEE 802.3
> Figure 37-6 specifies the signal that triggers an auto-negotiation
> restart as being "mr_restart_an=TRUE".
>
> Furthermore, clause "37.2.5.1.9 State diagram variable to management
> register mapping", through its "Table 37-8-PCS state diagram variable to
> management register mapping", requires a PCS compliant to clause 37 to
> expose the mr_restart_an signal to management through MDIO register "0.9
> Auto-Negotiation restart", aka BMCR_ANRESTART in Linux terms.
>
> The Felix PCS for SGMII and USXGMII is compliant to clause 37, so it
> exposes BMCR_ANRESTART to the operating system. When this bit is
> asserted, the following happens:
>
> 1. STATUS[Auto_Negotiation_Complete] goes from 1->0.
> 2. The PCS starts sending AN sequences instead of packets or IDLEs.
> 3. The PCS waits to receive AN sequences from PHY and matches them.
> 4. Once it has received matching AN sequences and a PHY acknowledge,
> STATUS[Auto_Negotiation_Complete] goes from 0->1.
> 5. Normal packet transmission restarts.
>
> Otherwise stated, the MAC PCS has the ability to re-trigger a switch of
> the lane from data mode into configuration mode, then control
> information exchange takes place, then the lane is switched back into
> data mode. These 5 steps are collectively described as "restart AN state
> machine" by the PCS documentation.
> This is all as per IEEE 802.3 Clause 37 AN state machine, which SGMII
> and USXGMII do not touch at this fundamental level.
>
> Now, it is true that the Cisco SGMII and USXGMII specs mention that the
> control information exchange has a unidirectional meaning. That is, the
> PHY restarts the clause 37 auto-negotiation upon any change in MDI
> auto-negotiation parameters.
>
> PHYLINK takes this fact a bit further, and since the fact that for
> SGMII/USXGMII, the MAC PCS conveys no new information to the PHY PCS
> (beyond acknowledging the received config word), does not have any use
> for permitting the MAC PCS to trigger a restart of the clause 37
> auto-negotiation.
>
> The only SERDES protocols for which PHYLINK allows that are 1000Base-X
> and 2500Base-X. For those, the control information exchange _is_
> bidirectional (local PCS specifies its duplex and flow control
> abilities) since the link partner is at the other side of the media.
>
> For any other SERDES protocols, the .phylink_mac_an_restart callback is
> dead code. This is probably OK, I can't come up with a situation where
> it might be useful for the MAC PCS to clear its cache of link state and
> ask for a new tx_config_reg.
>
> So remove this code.
NAK for this description. You know why.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2020-07-04 14:56 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-04 12:45 [PATCH v2 net-next 0/6] PHYLINK integration improvements for Felix DSA driver Vladimir Oltean
2020-07-04 12:45 ` [PATCH v2 net-next 1/6] net: dsa: felix: clarify the intention of writes to MII_BMCR Vladimir Oltean
2020-07-04 12:45 ` [PATCH v2 net-next 2/6] net: dsa: felix: support half-duplex link modes Vladimir Oltean
2020-07-04 12:45 ` [PATCH v2 net-next 3/6] net: dsa: felix: unconditionally configure MAC speed to 1000Mbps Vladimir Oltean
2020-07-04 12:45 ` [PATCH v2 net-next 4/6] net: dsa: felix: set proper pause frame timers based on link speed Vladimir Oltean
2020-07-04 12:45 ` [PATCH v2 net-next 5/6] net: dsa: felix: delete .phylink_mac_an_restart code Vladimir Oltean
2020-07-04 14:56 ` Russell King - ARM Linux admin [this message]
2020-07-04 15:50 ` Vladimir Oltean
2020-07-04 18:14 ` Russell King - ARM Linux admin
2020-07-04 20:29 ` Vladimir Oltean
2020-07-04 21:55 ` Russell King - ARM Linux admin
2020-07-04 12:45 ` [PATCH v2 net-next 6/6] net: dsa: felix: use resolved link config in mac_link_up() Vladimir Oltean
2020-07-05 22:26 ` [PATCH v2 net-next 0/6] PHYLINK integration improvements for Felix DSA driver David Miller
2020-07-06 8:45 ` Russell King - ARM Linux admin
2020-07-06 19:54 ` David Miller
2020-07-06 20:39 ` Russell King - ARM Linux admin
2020-07-06 20:46 ` David Miller
2020-07-06 20:53 ` Florian Fainelli
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=20200704145613.GR1551@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=alexandru.marginean@nxp.com \
--cc=andrew@lunn.ch \
--cc=claudiu.manoil@nxp.com \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=ioana.ciornei@nxp.com \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=vivien.didelot@gmail.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
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.