lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <eee39816-b0b8-475c-aa4a-8500ba488a29@lunn.ch> Date: Sat, 18 Nov 2023 21:19:40 +0100 From: Andrew Lunn <andrew@...n.ch> To: "Russell King (Oracle)" <linux@...linux.org.uk> Cc: Luo Jie <quic_luoj@...cinc.com>, davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com, robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org, hkallweit1@...il.com, corbet@....net, netdev@...r.kernel.org, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org Subject: Re: [PATCH v5 3/6] net: phy: at803x: add QCA8084 ethernet phy support > 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
Powered by blists - more mailing lists