linux-kernel - RE: [WARNING: ATTACHMENT UNSCANNED]Re: [PATCH RFC net-next 1/2] net: pcs: xpcs: Add special code to operate in Microchip KSZ9477 switch

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] [day] [month] [year] [list]

Message-ID:
 <DM3PR11MB87365F7DC7EBCA276BFD1D62ECE82@DM3PR11MB8736.namprd11.prod.outlook.com>
Date: Fri, 31 Jan 2025 02:35:51 +0000
From: <Tristram.Ha@...rochip.com>
To: <olteanv@...il.com>
CC: <linux@...linux.org.uk>, <Woojung.Huh@...rochip.com>, <andrew@...n.ch>,
	<hkallweit1@...il.com>, <maxime.chevallier@...tlin.com>,
	<davem@...emloft.net>, <edumazet@...gle.com>, <kuba@...nel.org>,
	<pabeni@...hat.com>, <UNGLinuxDriver@...rochip.com>,
	<netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: RE: [WARNING: ATTACHMENT UNSCANNED]Re: [PATCH RFC net-next 1/2] net:
 pcs: xpcs: Add special code to operate in Microchip KSZ9477 switch

> On Thu, Jan 30, 2025 at 04:50:18AM +0000, Tristram.Ha@...rochip.com wrote:
> > I explained in the other email that this SGMII_LINK_STS |
> > TX_CONFIG_PHY_SIDE_SGMII setting is only required for 1000BASEX where
> > C37_1000BASEX is used instead of C37_SGMII and auto-negotiation is
> > enabled.
> >
> > This behavior only occurs in KSZ9477 with old IP and so may not reflect
> > in current specs.  If neg_mode can be set in certain way that disables
> > auto-negotiation in 1000BASEX mode but enables auto-negotiation in SGMII
> > mode then this setting is not required.
> 
> I see that the KSZ9477 documentation specifies that these bits "must be
> set to 1 when operating in SerDes mode", but gives no explanation whatsoever,
> and gives the description of the bits that matches what I see in the
> XPCS data book (which suggests they would not be needed for 1000Base-X,
> just for SGMII PHY role).
> 
> There must exist a block guide of the Designware PCS that was integrated
> in KSZ9477 in the entire Microchip company. Or at least, the hardware
> architects must know what is going on. Can you help reconcile the XPCS
> specification with the KSZ9477 implementation? "The bits must be set" is
> not satisfactory when we are considering a common PCS driver. Were these
> bits overloaded by Microchip for 1000Base-X mode for KSZ9477?
> 
> At the very least, it sounds like it is improper to name these fields by
> their documented role for SGMII PHY mode, when clearly it is a different
> and undocumented role here.

Using this SGMII_LINK_STS | TX_CONFIG_PHY_SIDE_SGMII combination does not
have any side effect on the new IP even though it is no longer required
for 1000BASEX mode.

Note SGMII_LINK_STS | TX_CONFIG_PHY_SIDE_SGMII | C37_SGMII setting even
works for SGMII mode.  It seems this combination SGMII_LINK_STS |
TX_CONFIG_PHY_SIDE_SGMII reverts the effect of setting
TX_CONFIG_PHY_SIDE_SGMII so the SGMII module still acts as a MAC.

I will try to get the information from hardware designers.