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

Message-ID:
 <DM3PR11MB87369544966F3D2BD4584D38ECEB2@DM3PR11MB8736.namprd11.prod.outlook.com>
Date: Sat, 1 Feb 2025 01:11:54 +0000
From: <Tristram.Ha@...rochip.com>
To: <andrew@...n.ch>
CC: <linux@...linux.org.uk>, <olteanv@...il.com>, <Woojung.Huh@...rochip.com>,
	<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

> > > So I'm going to say it clearly: never operate the link with dis-similar
> > > negotiation protocols. Don't operate the link with 1000base-X at one end
> > > and Cisco SGMII at the other end. It's wrong. It's incorrect. The
> > > configuration words are different formats. The interpretation of the
> > > configuration words are different. Don't do it. Am I clear?
> >
> > I do not quite follow this.  The link partner is out of control.  The
> > cable is a regular Ethernet cable.  It can be plugged into another PHY, a
> > 100Mbit switch, and so on.  Currently using 1000Base-T SFP running in
> > 1000BASEX mode and 10/100/1000Base-T SFP running in Cisco SGMII mode
> > works in establishing network communication.
> 
> Russell is talking about PCS to PHY, the signalling over the SERDES
> bus. You are talking PHY-to-PHY signalling over the media, 4 pairs of
> copper. These are different signalling protocols, code words in the
> in-band signalling of the SERDES data stream, and pulses on the
> copper.
> 
> Russell is saying you should not mix a Cisco SGMII and 1000Base-X
> between the PCS and the PHY. The code words are different format,
> which might appear to work in some conditions, but in general is
> broken. This is why phylink will try to talk to the PHY within the
> SFP, and set is host side interface to Cisco SGMII, and configure the
> PCS to Cisco SGMII.
> 
> > > If it's still that 1000base-X mode to another 1000base-X partner doesn't
> > > generate a link-down interrupt, then you will have no option but to use
> > > phylink's polling mode for all protocols with this version of XPCS.
> >
> > It is always that case when running in 1000BASEX mode using fiber SFP or
> > 1000Base-T copper SFP.
> 
> So in general, you would not use 1000BaseX between the PCS and the PHY
> in the SFP. It gets tricky doing 10/100Mbps. Since 1000BaseX is hard
> coded to 1G, there is no in-band signalling to say to the MAC to only
> send at 10/100. So the PHY generally has back to back MACs, the host
> side running at 1000, and the line side at 10/100, with a packet
> buffer in the middle. As the buffer fills up, the host side MAC
> generates pause frames to slow down the MAC to stop the buffer
> overflowing.
 
I suspected that was the case.  But setting C37_SGMII for 1000BASEX SFP
or C37_1000BASEX for SGMII SFP will never work, so there is no situation
to mix them up.  The only concern is using SGMII_LINK_STS and
TX_CONFIG_PHY_SIDE_SGMII in 1000BASEX mode, and from the IP document
indeed it does not make sense.