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: Windows password security audit tool. GUI, reports in PDF.

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

Date: Thu, 3 Aug 2023 10:20:22 +0800
From: Jiawen Wu <jiawenwu@...stnetic.com>
To: "'Russell King \(Oracle\)'" <linux@...linux.org.uk>
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

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

Hi Russell,

I really don't know how to deal with "MAC side SGMII", could you please
help me?

>From the test results, when I config PCS in "PHY side SGMII", the link status
of PHY in copper SFP is read by I2C after AN complete. Then PHY's link up
status is informed to PHYLINK, then PCS will check its status. But when I just
change PCS to "MAC side SGMII", I2C will keep reading timeouts since AN
complete. I checked the register of PCS to confirm AN complete, but PHY's
link status would never be updated in PHYLINK.

It's kind of weird to me, how does the configuration of PCS relate to I2C?

Thanks!