Re: 10G-QXGMII phy no autonegotiation on LS1028A

[Vladimir Oltean <vladimir.oltean@nxp.com>]

Hi,

On Thu, Feb 26, 2026 at 12:26:30AM +0100, Andrew Lunn wrote:
> The call which is supposed to start autoneg is lynx_pcs_an_restart().
> 
> static void lynx_pcs_an_restart(struct phylink_pcs *pcs)
> {
>         struct lynx_pcs *lynx = phylink_pcs_to_lynx(pcs);
> 
>         phylink_mii_c22_pcs_an_restart(lynx->mdio);
> }
> 
> This is hitting the normal MII_BMCR, where as it seems like USXGMII
> has all it registers in MDIO_MMD_VEND2. Does this go together with
> what you found?
> 
> The problem here is, lynx_pcs_an_restart() is not passed the interface
> mode, so there is no obvious indication you should be using
> MDIO_MMD_VEND2. Probably lynx_pcs_config() needs to store away ifmode
> in struct lynx_pcs.

This is the wrong path. phylink_pcs_an_restart() only calls
pl->pcs->ops->pcs_an_restart() if
phy_interface_mode_is_8023z(pl->link_config.interface), which
PHY_INTERFACE_MODE_10G_QXGMII is not. It is by API design that this
won't be called.

> On Wed, Feb 25, 2026 at 09:32:28AM +0100, Patryk wrote:
> > The problem is as follows - the pcs-lynx correctly detect the USXGII
> > link however does not detect the link partner ability thus, the link
> > never becomes functional. It looks like the autonegotiation on the SoC
> > side does not work at all. I browsed through the pcs-lynx sources,
> > looking at the LS1028A reference manual, and I've found that Serdes
> > module on this SoC features some MDIO devices, whereas one of them is
> > "QXGMII USXGMII Replicator" (LS1028ARM 29.6 MDIO register spaces for
> > anyone interested). I checked this device and it features the Control
> > Register, which contains the Auto_Negotiation_Enable bit that is never
> > set by the pcs-lynx driver.
> 
> I'm not the expert here. Adding Vladimir and Ioana to Cc:

The problem that Patryk has identified is correct. Both PCS and PHY
in-band auto-negotiation used to rely on U-Boot pre-configuration to be
in sync.

To bring some context, the U-Boot driver for the Felix switch does
enable in-band auto-negotiation here:
https://github.com/u-boot/u-boot/blob/master/drivers/net/mscc_eswitch/felix_switch.c#L200-L201
so the reason why Patryk is seeing this issue is probably because he is
not using that driver.

Not depending on U-Boot pre-configuration is obviously a great goal, but
the infrastructure just hasn't existed until very recently. Again, it's
a combination of PHY and PCS settings, not exclusively a PHY or a PCS issue.
This is not the only place where an implicit dependency upon U-Boot has
existed.

I've tried to fix this before:
https://lore.kernel.org/netdev/20221118000124.2754581-1-vladimir.oltean@nxp.com/
but due to various reasons, it was a too complex issue for me then, and
Russell King finally introduced the framework based on LINK_INBAND_DISABLE |
LINK_INBAND_ENABLE relatively recently (Dec 2024).

Without Russell's framework, we would have no tool to set the PHY
in-band settings in sync with the PCS. And PHYs may be paired with any
other PCS, which may have different expectations. So hardcoding any
setting in the PHY driver is an obvious regression risk.

What we are looking at here are the loose ends for 10G-QXGMII, where the
Linux driver was just assuming that U-Boot would pre-initialize in-band
autoneg, and just validate that the device tree has
managed = "in-band-status". This is obviously insufficient for the new
world where we have API in place to ensure PHY and PCS settings are in
sync.

The good news, so to speak, is that I am not expecting regressions if we
were to configure 10G-QXGMII in-band autoneg in phylink_pcs_config()
according to the passed neg_mode, and remove the "%s only supports in-band AN for now\n"
limitation.

Patryk, which PHY are you working with? Are you able to also patch its
phylib driver so as to report both LINK_INBAND_DISABLE | LINK_INBAND_ENABLE
in its inband_caps() method? It would be great if the mode without
managed = "in-band-status" would also work. My notes on this topic while
I was working with the AQR412C didn't show a clear procedure on how to
disabled 10G-QXGMII in-band auto-negotiation.

How do you wish we proceed? Is the above context enough for you to
submit patches, or do you need assistance?