Re: [PATCH RFC net-next 1/2] net: pcs: xpcs: Add special code to operate in Microchip KSZ9477 switch

[Vladimir Oltean <olteanv@gmail.com>]

On Tue, Jan 28, 2025 at 09:24:45AM +0000, Russell King (Oracle) wrote:
> On Mon, Jan 27, 2025 at 07:32:25PM -0800, Tristram.Ha@microchip.com wrote:
> > For 1000BaseX mode setting neg_mode to false works, but that does not
> > work for SGMII mode.  Setting 0x18 value in register 0x1f8001 allows
> > 1000BaseX mode to work with auto-negotiation enabled.
> 
> I'm not sure (a) exactly what the above paragraph is trying to tell me,
> and (b) why setting the AN control register to 0x18, which should only
> affect SGMII, has an effect on 1000BASE-X.
> 
> Note that a config word formatted for SGMII can result in a link with
> 1000BASE-X to come up, but it is not correct. So, I highly recommend you
> check the config word sent by the XPCS to the other end of the link.
> Bit 0 of that will tell you whether it is SGMII-formatted or 802.3z
> formatted.

I, too, am concerned about the sentence "setting neg_mode to false works".
If this is talking about the only neg_mode field that is a boolean, aka
struct phylink_pcs :: neg_mode, then setting it to false is not
something driver customizable, it should be true for API compliance,
and all that remains false in current kernel trees will eventually get
converted to true, AFAIU. If 1000BaseX works by setting xpcs->pcs.neg_mode
to false and not modifying anything else, it should be purely a
coincidence that it "works", since that makes the driver comparisons
with PHYLINK_PCS_NEG_* constants meaningless.

> According to the KSZ9477 data, the physid is 0x7996ced0 (which is the
> DW value according to the xpcs header file). We also read the PMA ID
> (xpcs->info.pma). Can this be used to identify the KSZ9477 without
> introducing quirks?

If nothing else works, and it turns out that different IP integrations
report the same value in ID registers but need different handling, then
in principle the hack approach is also on the table. SJA1105, whose
hardware reads zeroes for the ID registers, reports a fake and unique ID
for the XPCS to identify it, because it, like the KSZ9477 driver, is in
control of the MDIO read operations and can selectively manipulate their
result.