From: Vladimir Oltean <olteanv@gmail.com>
To: Tristram.Ha@microchip.com
Cc: linux@armlinux.org.uk, Woojung.Huh@microchip.com, andrew@lunn.ch,
hkallweit1@gmail.com, maxime.chevallier@bootlin.com,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, UNGLinuxDriver@microchip.com,
netdev@vger.kernel.org, linux-kernel@vger.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
Date: Thu, 30 Jan 2025 12:02:27 +0200 [thread overview]
Message-ID: <20250130100227.isffoveezoqk5jpw@skbuf> (raw)
In-Reply-To: <DM3PR11MB873652D36F1FC20999F45772ECE92@DM3PR11MB8736.namprd11.prod.outlook.com>
On Thu, Jan 30, 2025 at 04:50:18AM +0000, Tristram.Ha@microchip.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.
next prev parent reply other threads:[~2025-01-30 10:02 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-28 3:32 [PATCH RFC net-next 0/2] Add SGMII port support to KSZ9477 switch Tristram.Ha
2025-01-28 3:32 ` [PATCH RFC net-next 1/2] net: pcs: xpcs: Add special code to operate in Microchip " Tristram.Ha
2025-01-28 9:24 ` Russell King (Oracle)
2025-01-28 10:21 ` Vladimir Oltean
2025-01-28 12:33 ` Russell King (Oracle)
2025-01-28 15:23 ` Vladimir Oltean
2025-01-28 16:32 ` Russell King (Oracle)
2025-01-28 18:26 ` Vladimir Oltean
2025-01-29 0:31 ` Tristram.Ha
2025-01-29 21:12 ` Vladimir Oltean
2025-01-29 22:05 ` Russell King (Oracle)
2025-01-29 23:05 ` Vladimir Oltean
2025-01-30 12:44 ` Russell King (Oracle)
2025-01-30 17:42 ` Russell King (Oracle)
2025-01-30 4:50 ` [WARNING: ATTACHMENT UNSCANNED]Re: " Tristram.Ha
2025-01-30 10:02 ` Vladimir Oltean [this message]
2025-01-30 11:02 ` Russell King (Oracle)
2025-01-30 11:20 ` Jose Abreu
2025-01-31 14:36 ` Jose Abreu
2025-01-31 15:49 ` Russell King (Oracle)
2025-02-01 1:12 ` [WARNING: ATTACHMENT UNSCANNED]Re: " Tristram.Ha
2025-02-01 9:20 ` Russell King (Oracle)
2025-01-31 2:35 ` Tristram.Ha
2025-01-30 10:15 ` Russell King (Oracle)
2025-01-31 2:35 ` Tristram.Ha
2025-01-31 13:35 ` Andrew Lunn
2025-02-01 1:11 ` Tristram.Ha
2025-01-30 4:50 ` Tristram.Ha
2025-01-30 9:59 ` Russell King (Oracle)
2025-01-31 2:24 ` Tristram.Ha
2025-01-31 9:43 ` Russell King (Oracle)
2025-01-30 13:24 ` Andrew Lunn
2025-01-31 2:21 ` Tristram.Ha
2025-01-28 12:40 ` Russell King (Oracle)
2025-01-28 13:16 ` Andrew Lunn
2025-01-28 13:39 ` Russell King (Oracle)
2025-01-28 15:43 ` Vladimir Oltean
2025-01-29 0:31 ` Tristram.Ha
2025-01-28 3:32 ` [PATCH RFC net-next 2/2] net: dsa: microchip: Add SGMII port support to " Tristram.Ha
2025-01-28 9:38 ` Russell King (Oracle)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250130100227.isffoveezoqk5jpw@skbuf \
--to=olteanv@gmail.com \
--cc=Tristram.Ha@microchip.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=Woojung.Huh@microchip.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=maxime.chevallier@bootlin.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox