[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250130100227.isffoveezoqk5jpw@skbuf>
Date: Thu, 30 Jan 2025 12:02:27 +0200
From: Vladimir Oltean <olteanv@...il.com>
To: Tristram.Ha@...rochip.com
Cc: linux@...linux.org.uk, 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:
> 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 behavior only occurs in KSZ9477 with old IP and so may not reflect
> in current specs. If neg_mode can be set in certain way that disables
> auto-negotiation in 1000BASEX mode but enables auto-negotiation in SGMII
> mode then this setting is not required.
I see that the KSZ9477 documentation specifies that these bits "must be
set to 1 when operating in SerDes mode", but gives no explanation whatsoever,
and gives the description of the bits that matches what I see in the
XPCS data book (which suggests they would not be needed for 1000Base-X,
just for SGMII PHY role).
There must exist a block guide of the Designware PCS that was integrated
in KSZ9477 in the entire Microchip company. Or at least, the hardware
architects must know what is going on. Can you help reconcile the XPCS
specification with the KSZ9477 implementation? "The bits must be set" is
not satisfactory when we are considering a common PCS driver. Were these
bits overloaded by Microchip for 1000Base-X mode for KSZ9477?
At the very least, it sounds like it is improper to name these fields by
their documented role for SGMII PHY mode, when clearly it is a different
and undocumented role here.
Powered by blists - more mailing lists