netdev - Re: [PATCH v5 3/6] net: phy: at803x: add QCA8084 ethernet phy support

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZVsnFWzi6KMXpJOj@shell.armlinux.org.uk>
Date: Mon, 20 Nov 2023 09:29:57 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Jie Luo <quic_luoj@...cinc.com>
Cc: Andrew Lunn <andrew@...n.ch>, 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

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.

> 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.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!