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+).
