linux-kernel - RE: [PATCH net-next v2] net: dsa: microchip: Add SGMII port support to 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:
 <DM3PR11MB87360344983B11FF6485B2F9ECE62@DM3PR11MB8736.namprd11.prod.outlook.com>
Date: Tue, 21 Jan 2025 03:08:31 +0000
From: <Tristram.Ha@...rochip.com>
To: <andrew@...n.ch>
CC: <olteanv@...il.com>, <maxime.chevallier@...tlin.com>,
	<Woojung.Huh@...rochip.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: [PATCH net-next v2] net: dsa: microchip: Add SGMII port support
 to KSZ9477 switch

> > > 0x1f8001 needs to be written 0x18 in 1000BaseX mode, but the XPCS driver
> > > does not do anything, and bit 4 is not defined in the driver.
> >
> > Does the Synopsis data book describe this bit, for the version of the
> > IP you have? Is it described in later version?
> 
> It is definitely defined in Synopsys SGMII IP document Microchip used.
> It is named SGMII_LINK_STS where 1 means link up and 0 means link down.
> It is used in combination with TX_CONFIG, bit 3.
> 
> It appears in latest SGMII IP document where 2.5G is supported.  To use
> 2.5G some other registers need to be changed to set the clock.  This
> procedure does not seem to appear in XPCS driver for the Synopsys IP.  I
> think a similar pma_config like NXP can be added, so I wonder if the 2.5G
> support is complete.
> 
> The KSZ9477 SGMII module has a bug that the MII_BMCR register needs to be
> updated with the correct speed when the link speed is changed in SGMII
> mode.  The XPCS driver seems to skip that in the link_up API.
> 
> The device id for Sysnopsys is 0x7996ced0.  It does not have any revision
> so it cannot be used for differentiation.
> 
> I can send a patch with RFC label for somebody to verify the code, but I
> do not really know how to update the XPCS driver to not break other
> DesignWare implementations if the new code is not compatible.

Additional comments:

If neg_mode is set to false in the XPCS driver then it works for
1000BaseX mode as auto-negotiation is disabled, but then it does not work
in SGMII mode as auto-negotiation is required.  When 0x18 is written
enabling auto-negotiation still works for 1000BaseX mode.

As MII_BMCR needs to be updated for different speeds in SGMII mode the
check for neg_mode needs to be changed, and auto-negotiation needs to be
enabled.  This bug workaround needs to be done somehow with other means.

The initial check for link returns invalid link up as it just compares
the interrupt bit value.  This is incorrect in SGMII mode.  It can be
fixed with additional check for 1000BaseX mode.