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.
when the PHY works on SGMII mode, then there is no xpcs, the only fourth
PHY of qca8084 can work on SGMII mode, the link topology:
the fourth PHY --- PCS --- PMA, the SGMII block includes PCS and PMA.
Either 10G-QXGMII or SGMII block of qca8084 connects with the interface
block(10G-QXGMII or SGMII) in MAC side.
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.
Thanks,
