Messages in this thread | | | Date | Tue, 21 Nov 2023 19:01:02 +0800 | Subject | Re: [PATCH v5 3/6] net: phy: at803x: add QCA8084 ethernet phy support | From | Jie Luo <> |
| |
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.
| |