[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<DM3PR11MB87365983C47EB7104CC4E9FDECE62@DM3PR11MB8736.namprd11.prod.outlook.com>
Date: Tue, 21 Jan 2025 00:28:19 +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.
Powered by blists - more mailing lists