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:
 <DM3PR11MB87366C1AC27378BA32D9CD9FEC242@DM3PR11MB8736.namprd11.prod.outlook.com>
Date: Fri, 15 Nov 2024 02:00:11 +0000
From: <Tristram.Ha@...rochip.com>
To: <andrew@...n.ch>
CC: <Woojung.Huh@...rochip.com>, <olteanv@...il.com>, <robh@...nel.org>,
	<krzk+dt@...nel.org>, <conor+dt@...nel.org>, <davem@...emloft.net>,
	<edumazet@...gle.com>, <kuba@...nel.org>, <pabeni@...hat.com>,
	<marex@...x.de>, <UNGLinuxDriver@...rochip.com>,
	<devicetree@...r.kernel.org>, <netdev@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH net-next 2/2] net: dsa: microchip: Add SGMII port support
 to KSZ9477 switch

> > When the SFP EEPROM says it does not support 1000Base-T then the SFP bus
> > code does not consider the SFP has a PHY and skips creating a MDIO bus
> > for it and phylink_sfp_config_optical() is called to create the phylink.
> 
> There are many SFPs out there with broken EEPROM contents. Do the SFPs
> you have say they are not 1000Base-T but actually are? If so, they are
> broken, and need a quirk adding.
> 
> Russell King keeps a database of SFP EEPROM contents. Send him the
> output of `ethtool -m eth42 raw on hex on`
> 
> > Now back to the discussion of the different modes used by the SGMII
> > module.  I think a better term like SerDes can be used to help
> > understanding the operation, although I still cannot narrow down the
> > precise definitions from looking at the internet.  SGMII mode is
> > said to support 10/100/1000Mbit.  This is the default setting, so
> > plugging such SFP allows the port to communicate without any register
> > programming.  The other mode is SerDes, which is fixed at 1000Mbit.  This
> > is typically used by SFP using fiber optics.  This requires changing a
> > register to make the port works.  It seems those 1000Base-T SFPs all run
> > in SerDes mode, at least from all SFPs I tried.
> 
> There is a comment in the code:
> 
> /* Probe a SFP for a PHY device if the module supports copper - the PHY
>  * normally sits at I2C bus address 0x56, and may either be a clause 22
>  * or clause 45 PHY.
>  *
>  * Clause 22 copper SFP modules normally operate in Cisco SGMII mode with
>  * negotiation enabled, but some may be in 1000base-X - which is for the
>  * PHY driver to determine.
> 
> So the default is SGMII for copper SFPs, but there are a few oddballs
> using 1000BaseX. The Marvell PHY driver should figure this out, and
> the phylink will tell you want mode to use.

Adding Marvell PHY driver fixes the main issue I raised.  But the PHY
support still shows only SGMII interface inside the PHY driver, and the
ethtool module-info command shows 1000BASE-T.  The only good brand-name
SFPs I have are all 10/100/1000 type.  I am going to get other brands to
see if they get better or always use SerDes mode.

That leaves the one situation where the SGMII port is connected directly
to a MAC or each other.  A customer once tried to do that and the SGMII
register write was changed to support that, but I do not know if that
project became a real product.  Microchip does have a board connecting
the SGMII ports of two chips together, but that does not run Linux, and
there is no special configuration to make the ports work.

As there is no SFP or PHY to tell phylink which interface to use I think
the only solution is to declare fixed-link or some other phy modes in the
device tree?

I currently use fixed-link to handle this situation.  There is another
new issue though.

The SGMII port in another chip can use 2.5G.  The driver uses fixed PHY
to get the MAC running.  But the fixed PHY driver can only support speed
up to 1000.  There is no issue to adding higher speeds to that driver, but
I think that is not advised?


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ