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

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 for Android: free password hash cracker in your pocket

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

Date: Fri, 28 Jul 2023 11:33:55 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Jiawen Wu <jiawenwu@...stnetic.com>
Cc: netdev@...r.kernel.org, andrew@...n.ch, hkallweit1@...il.com,
	Jose.Abreu@...opsys.com, mengyuanlou@...-swift.com
Subject: Re: [PATCH net-next 4/7] net: pcs: xpcs: adapt Wangxun NICs for
 SGMII mode

On Fri, Jul 28, 2023 at 06:11:51PM +0800, Jiawen Wu wrote:
> 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.
> 
> There is a question about I2C MII read ops. I see that PHY in SFP-RJ45 module
> is read by i2c_mii_read_default_c22(), but it limits the msgs[0].len=1.
> 
> A description in  the SFP-RJ45 datasheet shows:
> The registers are accessible through the 2-wire serial CMOS EEPROM protocol
> of the ATMEL AT24C01A or equivalent. The address of the PHY is 1010110x,
> where x is the R/W bit. Each register's address is 000yyyyy, where yyyyy is the
> binary equivalent of the register number. Write and read operations must send
> or receive 16 bits of data, so the "multi-page" access protocol must be used.
> 
> So the PHY register address should be written twice: first high 8 bits, second low
> 8 bits. to read the register value.
> 
> Is there a problem with which driver?

No there isn't, and it conforms with the above.

A read looks like this:

      Address  Data                   Address  Data     Data
Start 10101100 000yyyyy RepeatedStart 10101101 DDDDDDDD DDDDDDDD Stop
                      or Stop followed
		          by Start

The terms "Address" and "Data" here are as per the I²C specification.
You will notice that the first part has one byte of address and *one*
byte of data to convey the register address. This is what the "1" you
are referring to above is for.

For completness, a write looks like this:

      Address  Data     Data     Data
Start 10101100 000yyyyy DDDDDDDD DDDDDDDD Stop

Essentially, in all cases, when 0x56 is addressed with the data
direction in write mode, the very first byte is _always_ the register
address and the remainder contain the data. When the data direction is
in read mode, the bytes are always data.

The description you quote above is poor because it doesn't make it
clear whether "read" and "write" apply to the bus transactions or to
the device operations. However, I can assure you that what is
implemented is correct, since this is the standard small 24xx memory
device protocol, and I've been programming that on various
microcontrollers and such like for the last 30 years.

Are you seeing a problem with the data read or written to the PHY?

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