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? 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+". 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. 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. 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. 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. 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. 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. 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. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
