Re: [PATCH net v2] net: pcs: enable autonegotiation for 10g-usxgmii

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

On Wed, Aug 26, 2026 at 09:37:45AM +0200, Patryk Biel wrote:
> Hi Vladimir,
> 
> On Tue, Aug 25, 2026 at 11:49 PM Vladimir Oltean <olteanv@gmail.com> wrote:
> > There are multiple differences compared to U-Boot does. I haven't yet
> > been able to definitively determine the cause for regression. I'll debug
> > more tomorrow. Preliminary testing shows that any link timer values > 0.84 ms
> > will cause in-band autoneg to not complete with this combination.
> >
> > To be clear, does your board work with this patch?
> 
> Yes I tested it, I can provide you any logs you would find useful.
> Below is just a short log from interface bring up and simple iperf3
> test:
> 
> root@tru-:~# ip link set up swp0
> [   60.159618] mscc_felix 0000:00:00.5 swp0: configuring for
> inband/10g-qxgmii link mode
> [   63.308354] mscc_felix 0000:00:00.5 swp0: Link is Up - 1Gbps/Full -
> flow control off
> root@tru-:~# ip addr add 192.168.10.2/24 dev swp0
> root@tru-:~# iperf3 -s 192.168.10.2
> -----------------------------------------------------------
> Server listening on 5201 (test #1)
> -----------------------------------------------------------
> Accepted connection from 192.168.10.1, port 44470
> [  5] local 192.168.10.2 port 5201 connected to 192.168.10.1 port 44484
> [ ID] Interval           Transfer     Bitrate
> [  5]   0.00-1.00   sec   111 MBytes   933 Mbits/sec
> [  5]   1.00-2.00   sec   111 MBytes   934 Mbits/sec
> [  5]   2.00-3.00   sec   112 MBytes   935 Mbits/sec
> [  5]   3.00-4.00   sec   111 MBytes   934 Mbits/sec
> [  5]   4.00-5.00   sec   111 MBytes   934 Mbits/sec
> [  5]   5.00-6.00   sec   111 MBytes   934 Mbits/sec
> [  5]   6.00-7.00   sec   111 MBytes   934 Mbits/sec
> [  5]   7.00-8.00   sec   111 MBytes   934 Mbits/sec
> [  5]   8.00-9.00   sec   111 MBytes   934 Mbits/sec
> [  5]   9.00-10.00  sec   111 MBytes   934 Mbits/sec
> [  5]  10.00-10.24  sec  2.25 MBytes  77.7 Mbits/sec
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval           Transfer     Bitrate
> [  5]   0.00-10.24  sec  1.09 GBytes   914 Mbits/sec                  receiver
> 
> Will also try to find out what could possibly go wrong.
> 
> Best regards
> Patryk

Thanks for confirming.

I suspect our documentation is wrong, in that both for USXGMII and for
10G-QXGMII, we have the same text:

  Set the Link Timer value from 0 to 6.4ms in 3.2ns steps (312.5MHz clock
  periods or 312.5 million XGMII columns per second). The reset value sets
  the Link Timer to 1ms (312500).

But when you think about it, 10G-QXGMII multiplexes 4 ports over the
same lane. So each XGMII receives one block at 1/4 the rate of the lane,
because of the time slicing. Consequently, by my logic, the PCS link
timer, which uses the rate of those columns to keep track of time,
*can't* have the same link timer tick for both the single-port as for
the multi-port mode.

I was suspicious of the link timer limit I obtained (263050 ticks,
corresponding to the ~0.84 ms I was talking about yesterday). Higher
than that, and the AQR412C system side autoneg would restart (and a PHY
counter would continuously increase, indicating this). Furthermore, the
AQR412C system side PCS would never lose block lock.

So I wanted to see whether an ENETC, using the single-port USXGMII mode,
could also make its AQR112 PHY to fail in-band autoneg in the same way.
And surprise, I could, by increasing the link timer to 1037500 ticks.
Surprisingly (or not), the maximum # of link timer ticks for USXGMII is
3.94x the maximum # of link timer ticks for 10G-QXGMII.

So actually, I suspect that when we program a link_timer of
LINK_TIMER_VAL(1600000 ns) on 10G-QXGMII, in reality this results in a
link timer of 6.4 ms. And my AQR412C doesn't like a value this large.

The above is pure speculation/intuition, but it's the only thing that
seems to be consistent with all data so far. The only unknown is - why
does your PHY tolerate a link timer value that the AQR412C doesn't, and
will it work when we set the link timer to 1/4 that value?

Could you please test the diff below, which should give us the info to
the second question?

diff --git a/drivers/net/pcs/pcs-lynx.c b/drivers/net/pcs/pcs-lynx.c
index 305740b577fc..735ef4069a7f 100644
--- a/drivers/net/pcs/pcs-lynx.c
+++ b/drivers/net/pcs/pcs-lynx.c
@@ -24,8 +24,11 @@
 #define IF_MODE_SPEED_MSK		GENMASK(3, 2)
 #define IF_MODE_HALF_DUPLEX		BIT(4)

-/* USXGMII replicator link timer step is 3.2 ns (312.5 MHz clock) */
-#define USXGMII_LINK_TIMER_VAL(ns)	((u32)((ns) * 10 / 32))
+/* USXGMII replicator link timer step is 3.2 ns (312.5M XGMII columns per sec)
+ * for single port mode. For quad port mode, it is 1/4 of that.
+ */
+#define LINK_TIMER_VAL_USXGMII(ns)	((u32)((ns) * 10 / 32))
+#define LINK_TIMER_VAL_10G_QXGMII(ns)	((u32)((ns) * 10 / 128))

 struct lynx_pcs {
 	struct phylink_pcs pcs;
@@ -187,7 +190,10 @@ static int lynx_pcs_config_usxgmii(struct mdio_device *pcs,

 	link_timer_ns = phylink_get_link_timer_ns(interface);
 	if (link_timer_ns > 0) {
-		link_timer = USXGMII_LINK_TIMER_VAL(link_timer_ns);
+		if (interface == PHY_INTERFACE_MODE_10G_QXGMII)
+			link_timer = LINK_TIMER_VAL_10G_QXGMII(link_timer_ns);
+		else
+			link_timer = LINK_TIMER_VAL_USXGMII(link_timer_ns);

 		ret = mdiobus_c45_write(bus, addr, MDIO_MMD_VEND2,
 					LINK_TIMER_LO, link_timer & 0xffff);