On 11/20/2023 5:29 PM, Russell King (Oracle) wrote:
On Mon, Nov 20, 2023 at 04:49:59PM +0800, Jie Luo wrote:
On 11/19/2023 4:19 AM, Andrew Lunn wrote:
10G_QXGMII is defined in the Cisco USXGMII multi-port document as one
of several possibilities for a USXGMII-M link. The Cisco document can
be a little confusing beause it states that 10G_QXGMII supports 10M,
100M, 1G and 2.5G, and then only talks about a 10G and 100M/1G MAC.
For 10G_QXGMII, there are 4 MAC interfaces. These are connected to a
rate "adaption" through symbol replication block, and then on to a
clause 49 PCS block.
There is then a port MUX and framing block, followed by the PMA
serdes which communicates with the remote end over a single pair of
transmit/receive serdes lines.
Each interface also has its own clause 37 autoneg block.
So, for an interface to operate in SGMII mode, it would have to be
muxed to a different path before being presented to the USXGMII-M
block since each interface does not have its own external data lane
- thus that's out of scope of USXGMII-M as documented by Cisco.
Hi Russell
I think it helps.
Where i'm having trouble is deciding if this is actually an interface
mode. Interface mode is a per PHY property. Where as it seems
10G_QXGMII is a property of the USXGMII-M link? Should we be
representing the package with 4 PHYs in it, and specify the package
has a PMA which is using 10G_QXGMII over USXGMII-M? The PHY interface
mode is then internal? Its just the link between the PHY and the MUX?
By saying the interface mode is 10G_QXGMII and not describing the PMA
mode, are we setting ourselves up for problems in the future? Could
there be a PMA interface which could carry different PHY interface
modes?
If we decide we do want to use 10G_QXGMII as an interface made, i
think the driver should be doing some validation. If asked to do
anything else, it should return -EINVAL.
And i don't yet understand how it can also do 1000BaseX and 2500BaseX
and SGMII?
Andrew
Hi Andrew,
The interface mode 10G_QXGMII is a type of USXGMII-M, the other modes
such as 20G-QXGMII, 20G-OXGMII...
As for the interface mode 10G-QXGMII, there is a multiplexer for 4 PHYs,
then do 66bit/68bit encode in xpcs and pass to PMA, the link topology:
quad PHY --- multiplexer ---XPCS --- PMA.
the 10G-QXGMII interface block includes multiplexer, XPCS and PMA.
Note that phylink_pcs does *not* cover any PCS on the PHY device side
of the link. It only covers a PCS on the MAC side.
Ok, even there is only one XPCS multiplex with 4 MACs, we should create
4 PCS instances for 4 MACs.
Here is a problem as Russell mentioned earlier, we need to know which PHY
device is changing the link status when the 10G-QXGMII mode is used,
since there are 4 PHYs, when one of them has the link change, there is no
PHY device information passed to the PHYLINK, so the PCS driver don't
which PHY is changing link status and 10G-QXGMII mode don't know which
channel(mapped to PHY) should be configured.
would we add a field such as (int channel) in the struct phy_device?
so we can pass this information to PCS driver when the PHY link changed.
Nothing in phylink nor phylib is setup to deal with "channels" within
a PHY. The model assumes that a network interface consists of exactly
one MAC associated with one active PHY.
As there are 4 PHYs, phylib will expect there to be four PHY devices,
and there will be expected to be four phylink instances.
make sense, thanks Russell.
