Re: [PATCH v5 3/6] net: phy: at803x: add QCA8084 ethernet phy support
flat view
From: Andrew Lunn <andrew@lunn.ch>
Date: 2023-11-18 20:20:05
Also in:
linux-devicetree, linux-doc, lkml
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