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

[Jie Luo]

On 11/13/2023 11:11 PM, Russell King (Oracle) wrote:
> On Fri, Nov 10, 2023 at 10:18:41AM +0100, Maxime Chevallier wrote:
> > On Fri, 10 Nov 2023 16:53:39 +0800
> > Jie Luo <quic_luoj@xxxxxxxxxxx> wrote:
> >
> > > On 11/9/2023 5:16 PM, Maxime Chevallier wrote:
> > > > Hello,
> > > >
> > > > On Thu, 9 Nov 2023 16:32:36 +0800
> > > > Jie Luo <quic_luoj@xxxxxxxxxxx> 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.
Yes, the half duplex is not supported by PCS.

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

That's true.
There are 4 channels of 10G-QXGMII PCS for mapping with quad PHY ports,
the port ID information of PCS needs be delivered to driver.

In the PCS driver, it seems we need to know the current channel of PCS
taking the link status change when the PHY link updated.