Subject: Re: [PATCH v2 1/3] net: phy: at803x: add QCA8084 ethernet phy support

From: "Russell King (Oracle)" <[email-masked]>
Date: Mon, 13 Nov 2023 15:11:44 +0000

On Fri, Nov 10, 2023 at 10:18:41AM +0100, Maxime Chevallier wrote:
> On Fri, 10 Nov 2023 16:53:39 +0800
> Jie Luo <[email-masked]> wrote:
> 
> > On 11/9/2023 5:16 PM, Maxime Chevallier wrote:
> > > Hello,
> > > 
> > > On Thu, 9 Nov 2023 16:32:36 +0800
> > > Jie Luo <[email-masked]> wrote:
> > > 
> > > [...]
> > >   
> > >>> What I understand from this is that this PHY can be used either as a
> > >>> switch, in which case port 4 would be connected to the host interface
> > >>> at up to 2.5G, or as a quad-phy, but since it uses QUSGMII the link
> > >>> speed would be limited to 1G per-port, is that correct ?  
> > >>
> > >> When the PHY works on the interface mode QUSGMII for quad-phy, all 4
> > >> PHYs can support to the max link speed 2.5G, actually the PHY can
> > >> support to max link speed 2.5G for all supported interface modes
> > >> including qusgmii and sgmii.  
> > > 
> > > I'm a bit confused then, as the USGMII spec says that Quad USGMII really
> > > is for quad 10/100/1000 speeds, using 10b/8b encoding.
> > > 
> > > Aren't you using the USXGMII mode instead, which can convey 4 x 2.5Gbps
> > >   with 66b/64b encoding ?
> > > 
> > > Thanks,
> > > 
> > > Maxime  
> > 
> > Hi Maxime,
> > Yes, for quad PHY mode, it is using 66b/64 encoding.
> > 
> > it seems that PHY_INTERFACE_MODE_USXGMII is for single port,
> > so i take the interface name PHY_INTERFACE_MODE_QUSGMII for
> > quad PHYs here.
> 
> I see, when I added the QUSGMII mode I wrongly stated that it came from
> the USXGMII spec where it really comes from USGMII, my bad.
> 
> > can we apply PHY_INTERFACE_MODE_USXGMII to quad PHYs in this
> > case(qca8084 quad PHY mode)?
> 
> From what I can see, the USXGMII mode in the kernel is used as the
> single-port 10G mode of usxgmii. You might need to create a new mode
> for quad usxgmii at 10G, the spec calls it 10G-QXGMII I think, but as
> the spec defines quite a lot of modes, should we define all of them or
> rely on some other parameters to select the actual mode ?
> 
> Andrew, Heiner, Russell, what do you think ?

Looking at the Cisco USXGMII Multiport Copper Interface specification,
you appear to be correct with the "10G-QXGMII" name. I note that it is
also specified that "System Interface operates in full duplex mode
only." and makes no other significant mention of duplex, so it's not
clear whether half duplex is supported on the media side.

Figure 2 in this document is the significant one that we need to
consider, as we're talking about N network interfaces connecting to a
system interface that then connects to a PHY with multiple ports.

Given our model, I think it's quite right to use "10G-QXGMII" because
that describes the protocol over the system interface that will be
used. However, we need to consider whether this is the only information
we need, or whether we need to also be thinking about expanding the
"pcs" property to something such as:

	pcs = <&usxgmiim_pcs PORT>;

where PORT is the port number on the USXGMII PHY as described by figure
2. It seems to me that a driver for this USXGMII PHY would need to know
the port information that a network interface is connected to.

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