Message-ID: <d2ac542c-aae3-49ae-ae2b-9defc4ca98eb@quicinc.com>
Date: Thu, 23 Nov 2023 18:57:59 +0800
From: Jie Luo <quic_luoj@...cinc.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
CC: Andrew Lunn <andrew@...n.ch>, <davem@...emloft.net>, <edumazet@...gle.com>,
        <kuba@...nel.org>, <pabeni@...hat.com>, <robh+dt@...nel.org>,
        <krzysztof.kozlowski+dt@...aro.org>, <conor+dt@...nel.org>,
        <hkallweit1@...il.com>, <corbet@....net>, <netdev@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-doc@...r.kernel.org>
Subject: Re: [PATCH v5 3/6] net: phy: at803x: add QCA8084 ethernet phy support



On 11/21/2023 7:52 PM, Russell King (Oracle) wrote:
> On Tue, Nov 21, 2023 at 07:10:08PM +0800, Jie Luo wrote:
>> when pcs is configured to SGMII mode, the fourth PHY can reach to
>> maximum speed 2.5G(2500BaseT) that is reached by increasing the clock
>> rate to 312.5MHZ from 125MHZ of 1G speed, but there is no corresponding
>> interface mode can be used to reflect this 2.5G speed mode(sgmii+)
> 
> So this comes up again. 2.5G SGMII? What is that?

2.5G SGMII here is reached by increasing the PCS clock rate to 312.5MHZ
from sgmii with the clock rate 125MHZ.

> 
> Let's start off with the basics. SGMII is Cisco's modification of
> 1000base-X. The two are broadly compatible in that they can communicate
> with each other provided that the inband control word is disregarded.
> 
> 2500base-X is generally implemented as 1000base-X over-clocked by 2.5x.
> Some manufacturers state that the inband control word is not supported.
> Others say it can be used. This disparity comes from the lack of early
> IEEE standardisation of this protocol.
> 
> Cisco SGMII as defined is a 10M/100M/1G protocol operating at 125MHz
> with a fixed underlying baud rate of 1250Mbaud. Slower speeds are
> achieved via symbol replication by 10x or 100x. The inband control
> word is modified in order to convey this speed information, as well
> as duplex and sometimes also other vendor extensions.
> 
> Switching SGMII to be clocked 2.5x faster means that a partner that
> expects SGMII at normal speed sees garbage - it can't recognise the
> waveform. Therefore, it is not possible for inband to convey any
> information. Many vendors explicitly state that symbol replication
> is not supported when "SGMII" is clocked at 2.5x.
> 
> All variants of whatever the vendor calls the 2.5G mode tend to use
> the SGMII term because... it's Serial Gigabit... and SGMII even gets
> used by vendors to describe the interface used for 1000base-X.
> Vendors use terms like "HS-SGMII" and other stuff to describe their
> 2.5x mode. Some use "2500base-X". Yours seems to use "SGMII+".

i use the term SGMII+ because of the 2.5G speed achieved by operating
the clock rate in 312.5MHZ from 1G speed of 125MHZ.

> 
> SGMII without inband signalling is basically the same as 1000base-X.
> Therefore, SGMII clocked at 2.5x the speed is basically the same as
> 2500base-X without inband signalling.

SGMII+ disable the autoneg when the serdes works 312.5MHZ for the 2.5
link speed.

> 
> So, the whole area is totally confused, and one should not get too
> hung up on the terminology that vendors are using, but go back to
> precisely what's going on at the hardware level.
> 
> We have raised this point almost every time someone talks about an
> up-clocked "SGMII".
> 
> 
>> Actually we should add a new interface mode such as sgmii+
>> to reflect this 2.5G speed of sgmii
> 
> Only if there really is something different about it. For example,
> if it were Cisco SGMII modified to operate always at 312.5MHz with
> inband signalling updated to signal the four speeds. That would
> definitely be a different protocol.

For qca808x PHY, the clock rate is different between sgmii(125MHZ for
speed 10/100/1000M) and sgmii+(312.5MHZ for 2.5G).

> 
> However, it's not that. What it actually is is Cisco SGMII when
> operating at 10M/100M/1G speeds, and 2500base-X without inband
> signalling when operating at 2.5G speed.

Yes, Russell, this is what qca808x PHY works on.

> 
> We have PHYs that support this (and more) which we support. PHYs
> that switch between 10GBASE-R, 5GBASE-R, 2500BASE-X and Cisco SGMII
> depending on the speed that was negotiated on the media. There is
> no definition of a single interface mode that covers all those,
> because it isn't a single interface mode. It's four separate modes
> that the PHY switches between - and this is no different from what
> is happening with your PHY.

This is indeed two different modes switched between 2.5G and other
speeds(10/100/1000M).

> 
> Ultimately, you will need a way to use inband signalling with Cisco
> SGMII for 10M/100M/1G speeds, and then switch to 2500base-X when
> operating at 2.5G speeds, and that is done via the PHY driver
> updating phydev->interface.
> 
> What we do need is some way for the PHY to also tell the PCS/MAC
> whether inband should be used. This is something I keep bringing up
> and now that we have PCS drivers revised to use the value from
> phylink_pcs_neg_mode() _and_ a consistent implementation amongst them
> we can now think about signalling to PCS drivers whether inband mode
> needs to be turned off when switching between modes.

Yes, we can switch the interface mode according to the current link
speed in the pcs driver.
but the issue is that the phy-mode i specified for the PHYLINK,
if phy-mode is sgmii, the support capability is limited to maximum
capability 1G during the PHYLINK setup and i can't configure it to 2.5G
dynamically, if the phy-mode is 2500base-x, then PHY capability will
be modified to only support 2.5G, other speeds can't be linked up.

> 
> There have been patches in the past that allow inband mode to be
> queried from phylib, and this is another important component in
> properly dealing with PHYs that need to use inband signalling with
> Cisco SGMII, but do not support inband signalling when operating at
> 2.5G speeds. The problem when operating at 2.5G speed is that the
> base-X protocols are normally for use over fibre, which is the media,
> and therefore the ethtool Autoneg bit should define whether inband
> gets used or not. However, in the case of a PHY using 2500base-X,
> the Autoneg bit continues to define whether autonegotiation should
> be used on the media, and in this case it's the media side of the
> PHY rather than the 2500base-X link.
> 
> So, when using a 2500base-X link to a PHY, we need to disregard the
> Autoneg bit, but that then raises the question about how we should
> configure it - and one solution to that would be to entire of phylib
> what the PHY wants to do. Another is to somehow ask the PCS driver
> whether it supports inband signalling at 2500base-X, and resolve
> those capabilities.

For the qca808x PHY, when it is linked in 2.5G, the autoneg is also
disabled in PCS hardware, so the sgmii+ of qca808x PHY is almost
same as 2500base-X.

> 
> That is my view where we need to get to in order to properly resolve
> the ongoing issues about 2500base-X and PHYs that make use of that.
> 

Thanks Russell for the detail information about the SGMII and 2500BASE-X
mode, it is really helpful.

For now, the issue is "the Supported link modes" of PHY is limited when
the interface mode(such as sgmii) is used to setup PHYLINK, which leads
to the PHY can't link in the speed(such as 2.5G) of the different
interface mode(sgmii+).

Powered by blists - more mailing lists