netdev - 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:
 <DM3PR11MB8736A58E065BF24C2CEA5808ECE82@DM3PR11MB8736.namprd11.prod.outlook.com>
Date: Fri, 31 Jan 2025 02:35:38 +0000
From: <Tristram.Ha@...rochip.com>
To: <linux@...linux.org.uk>
CC: <olteanv@...il.com>, <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:
> > > The next question would be whether it's something that we _could_
> > > always do - if it has no effect for anyone else, then removing a
> > > conditional simplifies the code.
> >
> > 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 sentence reads to me "if we want to use 1000base-X mode, and we
> configure the XPCS to use 1000base-X rather than Cisco SGMII then
> setting both SGMII_LINK_STS and TX_CONFIG_PHY_SIDE_SGMII bits are
> required.
> 
> Thanks, that tells me nothing that I don't already know. I know full
> well that hardware needs to be configured for 1000base-X mode to use
> 1000base-X negotiation. I also have been saying for some time that
> KSZ9477 documetation states that these two "SGMII" bits need to be
> set in 1000base-X mode.
> 
> This is not what I'm questioning here. What I am questioning is whether
> we can set these two "SGMII" bits _unconditionally_ in the
> xpcs_config_aneg_c37_1000basex() path in the driver without impacting
> newer XPCS IPs.

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.

So even though you said not to setup the module as a PHY it may not have
that effect.

However we will never know whether this will impact other IP unless
somebody tries them out.

> > The major difference between 1000BASEX and SGMII modes in KSZ9477 is
> > there are link up and link down interrupts in SGMII mode but only link up
> > interrupt in 1000BASEX mode.  The phylink code can use the SFP cage logic
> > to detect the fiber cable is unplugged and say the link is down, so that
> > may be why the implementation behaves like that, but that does not work
> > for 1000Base-T SFP that operates in 1000BASEX mode.
> 
> At this point, given all the discussion that has occurred, I'm really
> not sure how to take "only link up in 1000base-X mode" - whether you're
> talking about using 1000base-X with the other side operating in Cisco
> SGMII mode or whether you're talking about e.g. a fibre link.
> 
> 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.

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

> > > > > There are some SFPs
> > > > > that will use only 1000BaseX mode.  I wonder why the SFP manufacturers do
> > > > > that.  It seems the PHY access is also not reliable as some registers
> > > > > always have 0xff value in lower part of the 16-bit value.  That may be
> > > > > the reason that there is a special Marvell PHY id just for Finisar.
> > >
> > > I don't have any modules that have a Finisar PHY rather than a Marvell
> > > PHY. I wonder if the problem is that the Finisar module doesn't like
> > > multi-byte I2C accesses to the PHY.
> > >
> > > Another thing - make sure that the I2C bus to the SFP cage is running
> > > at 100kHz, not 400kHz.

> > What I meant is this Marvell PHY ID 0x01ff0cc0.  Basically it is
> > 0x01410cc0 for Marvell 88E1111 with 0x41 replaced with 0xff.  Some
> > registers like the status register even has 0xff value all the time so
> > the PHY can never report the link is down.
> 
> Which module does this happen with, and is it still available to buy
> (can I get one to test with?)

All of those SFPs have generic brands.  I bought them from Amazon and
FS.com.