10G-QXGMII phy no autonegotiation on LS1028A

10G-QXGMII phy no autonegotiation on LS1028A

[Patryk]

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 patched the driver (just out of
curiosity) and in lynx_pcs_config_usxgmii I added code that sets this
bit. Somehow after this change the autoneg state machine kicked-in and
pcs-lynx was able to detect the link partner abilities, the negotiated
speed and make the link functional. I was even able to exchange some
information through this link - ping, scp file.

But this is ofc - in my opinion - not the solution, as I just can't
believe that someone just forgot to set this bit in the pcs-lynx
driver, I guess that the real solution is somewhere else. If this bit
is not set in the driver then what makes the autoneg process enabled?
I'm wondering if perhaps someone here has done something like this
before and would like to share some hints on how to approach this? The
second question I have - I mentioned that I was able to establish
communication with the link partner, however there were some errors
especially while sending bigger packets, e.g. sending ping -s 20 ended
up with 100% success rate, however ping -s 300 ended with ~50% success
rate. I'm wondering how big of an impact on the communication quality
has the fact that the PHY I've been using is connected through the
connector, not directly soldered on the PCB? It's just my feeling -
but if I were to guess I would say that in the case of 10G QXGMII it
may be significant, but I'm not that experienced to be sure of this
statement.

Best regards
Patryk

Re: 10G-QXGMII phy no autonegotiation on LS1028A

[Andrew Lunn]

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

Re: 10G-QXGMII phy no autonegotiation on LS1028A

[Vladimir Oltean]

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?

Re: 10G-QXGMII phy no autonegotiation on LS1028A

[Patryk]

Hi,

czw., 26 lut 2026 o 13:36 Vladimir Oltean <vladimir.oltean@nxp.com> napisał(a):
> 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.

Indeed, I don't use this driver in u-boot.

> 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.
>
> 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.

Thanks for the detailed explanation, that makes sense now.

> 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.

As for the phy... I'm aware that this isn't ideal for community
visibility, but the PHY I'm working with has not been upstreamed yet
and is currently under a strict NDA. Unfortunately, I cannot disclose
the specific model at this stage. This is a constraint I'm bound by,
as I'm working with vendor-supplied sources. I can however patch the
vendor supplied sources adding modification you suggested so I guess
the phy will be working as expected.

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

Of course I’ll gladly prepare patches. Just to summarize what needs to be done:
- in lynx_pcs_config_usxgmii the constraint about in-band only
supported mode should be removed
- if neg_mode = PHYLINK_PCS_NEG_INBAND_ENABLED then the vendor
specific registers to enable and restart autoneg (similarly like in
u-boot) should be configured
- additionally it should also work without in-band-status defined in
the device tree

Is this what you're suggesting? I'll proceed with this unless you have
any objections.

Best regards
Patry

Re: 10G-QXGMII phy no autonegotiation on LS1028A

[Vladimir Oltean]

On Thu, Feb 26, 2026 at 05:09:59PM +0100, Patryk wrote:
> As for the phy... I'm aware that this isn't ideal for community
> visibility, but the PHY I'm working with has not been upstreamed yet
> and is currently under a strict NDA. Unfortunately, I cannot disclose
> the specific model at this stage. This is a constraint I'm bound by,
> as I'm working with vendor-supplied sources. I can however patch the
> vendor supplied sources adding modification you suggested so I guess
> the phy will be working as expected.

That's OK. If you can still test on your side with the PHY driver
implementing the inband caps API for both enabled and disabled, and
specify that you did that, I think we can operate on good faith in that
case. I may be able to hack up a PHY-less test rig to double check just
in case, and leave a Tested-by: tag. I can also do a regression test
with in-band autoneg enabled on AQR412C.

> > How do you wish we proceed? Is the above context enough for you to
> > submit patches, or do you need assistance?
> 
> Of course I’ll gladly prepare patches. Just to summarize what needs to be done:
> - in lynx_pcs_config_usxgmii the constraint about in-band only
> supported mode should be removed
> - if neg_mode = PHYLINK_PCS_NEG_INBAND_ENABLED then the vendor
> specific registers to enable and restart autoneg (similarly like in
> u-boot) should be configured
> - additionally it should also work without in-band-status defined in
> the device tree
> 
> Is this what you're suggesting? I'll proceed with this unless you have
> any objections.

Yep, sounds good. Don't forget to modify lynx_pcs_inband_caps() to make
PHY_INTERFACE_MODE_USXGMII and PHY_INTERFACE_MODE_10G_QXGMII to be
treated like the PHY_INTERFACE_MODE_1000BASEX family (aka report both
LINK_INBAND_DISABLE | LINK_INBAND_ENABLE).

Thanks!