Re: 10G-QXGMII phy no autonegotiation on LS1028A

[Andrew Lunn <andrew@lunn.ch>]

On Wed, Feb 25, 2026 at 09:32:28AM +0100, Patryk wrote:
> Hello, I've been trying to bring-up the 10G-QXGMII PHY on LS1028A
> based board and I have some problems. I guess that they come from the
> fact that I do not see the whole picture as this is the second phy
> I've been working on (actually the first one that uses serdes, the
> previous one was connected through RGMII). Anyway I decided to send
> this mail and post some of my questions hoping someone will find some
> time to steer a newbie in the right direction.
> 
> The phy I've been using, once started, autoconfigures to 10G-QXGMII
> mode with auto negotiation enabled. It detects the link partner
> abilities and completes the autoneg process (at least on the line
> side). I think we can assume it works as expected. From the SoC side,
> as I understand the crucial part is pcs-lynx implementation. It
> configures the USXGMII mode, checks the state, reads the link partner
> ability that is carried "in-band". and so on. In the device tree I
> configure my phy to use mode="in-band-status".
> 
> 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:

lynx_pcs_inband_caps() says:

        case PHY_INTERFACE_MODE_USXGMII:
        case PHY_INTERFACE_MODE_10G_QXGMII:
                return LINK_INBAND_ENABLE;

This is saying it does have the capability to do inband.

lynx_pcs_config() does:

       case PHY_INTERFACE_MODE_USXGMII:
        case PHY_INTERFACE_MODE_10G_QXGMII:
                return lynx_pcs_config_usxgmii(lynx->mdio, ifmode, advertising,
                                               neg_mode);

static int lynx_pcs_config_usxgmii(struct mdio_device *pcs,
                                   phy_interface_t interface,
                                   const unsigned long *advertising,
                                   unsigned int neg_mode)
{
        struct mii_bus *bus = pcs->bus;
        int addr = pcs->addr;

        if (neg_mode != PHYLINK_PCS_NEG_INBAND_ENABLED) {
                dev_err(&pcs->dev, "%s only supports in-band AN for now\n",
                        phy_modes(interface));
                return -EOPNOTSUPP;
        }

        /* Configure device ability for the USXGMII Replicator */
        return mdiobus_c45_write(bus, addr, MDIO_MMD_VEND2, MII_ADVERTISE,
                                 MDIO_USXGMII_10G | MDIO_USXGMII_LINK |
                                 MDIO_USXGMII_FULL_DUPLEX |
                                 ADVERTISE_SGMII | ADVERTISE_LPACK);
}

Looks sensible, setting what will be advertised.

> I patched the driver (just out of
> curiosity) and in lynx_pcs_config_usxgmii I added code that sets this
> bit.

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.

	Andrew