RE: [PATCH net-next 4/7] net: pcs: xpcs: adapt Wangxun NICs for SGMII mode

["Jiawen Wu" <jiawenwu@trustnetic.com>]

On Tuesday, July 25, 2023 6:08 PM, Russell King (Oracle) wrote:
> On Tue, Jul 25, 2023 at 10:58:25AM +0100, Russell King (Oracle) wrote:
> > > The information obtained from the IC designer is that "PHY/MAC side SGMII"
> > > is configured by experimentation. For these different kinds of NICs:
> > > 1) fiber + SFP-RJ45 module: PHY side SGMII
> > > 2) copper (pcs + external PHY): MAC side SGMII
> >
> > This makes no sense. a PHY on a RJ45 SFP module is just the same as a
> > PHY integrated into a board with the MAC.
> 
> 
> MAC ---- PCS <----- sgmii -----> PHY (whether on a board or SFP)
> 
> Control word flow:
>              <------------------ link, speed, duplex
> 	     ------------------> acknowledge (value = 0x4001)
> 
> Sometimes, it's possible to connect two MACs/PCSs together:
> 
> MAC ---- PCS <----- sgmii -----> PCS ---- MAC
> 
> and in this case, one PCS would need to be configured in "MAC" mode
> and the other would need to be configured in "PHY" mode because SGMII
> is fundamentally asymmetric.
> 
> Here is the definition of the control word sent by either end:
> 
> Bit	MAC->PHY	PHY->MAC
> 15	0: Reserved	Link status, 1 = link up
> 14	1: Acknowledge	Reserved for AN acknowledge
> 13	0: Reserved	0: Reserved
> 12	0: Reserved	Duplex mode 1 = full, 0 = half
> 11:10	0: Reserved	Speed 11 = Reserved 10=1G, 01=100M, 00=10M
> 9:1	0: Reserved	0: Reserved
> 0	1		1
> 
> So my guess would be that "PHY side SGMII" means the device generates
> the "PHY->MAC" format word whereas "MAC side SGMII" generates the
> "MAC->PHY" format word - and it's the latter that you want to be using
> both for Copper SFPs, which are no different from PHYs integrated onto
> the board connected with SGMII.

Thanks for the detailed explanation, I can understand it.

So I need to find out why config it in MAC mode doesn't work. When I config
it in MAC mode, PHY would not change state to callback the xpcs_get_state().
I dump the PCS register through the tool at this time, VR_MII_AN_INTR_STS
is not always the same value, sometimes AN complete, sometimes not.

I'm not sure if this is related to the anomaly, log often shows:
"i2c_designware i2c_designware.1024: timeout in disabling adapter"