Re: [PATCH net-next v9 08/11] net: dsa: realtek: rtl8365mb: re-latch the family D SerDes

[Stanislaw Pal]

Hi Johan,

On Tue, Nov 10, 2026 at 12:49:04AM -0500, Johan Alvarado wrote:
> Oleg, could you check this on the AX55 before the first ifup of the
> conduit? A single register read tells:
>
>   devmem 0x98218    # UNIPHY MISC2: 0x70 = SGMII, 0x50 = SGMII+

I can't answer for Oleg's unit. Mine is an Archer AX55 v1 with an
RTL8367S, family C like your MR80X v2, so this is a second family C
board, not the family D answer.

That image has no /dev/mem, so I printed MISC2 and MODE_CTRL from
qca-uniphy instead: at probe, around your preconfig, and before and
after every pcs_config(). On every boot, warm and cold, probe reads
MISC2 0x70 and MODE_CTRL 0x421. Without your commit, SGMII+ (0x50,
0x821) shows up at the first pcs_config(), at about 7.4 s, while the
switch configures 2500base-x at about 5.0 s.

One note on the values. In the pcs-qca-uniphy table, MISC2[6:4] = 7
(0x70) is the USXGMII value; SGMII is 0x30 and SGMII+ is 0x50, as
FlyFish-go pointed out on an RC3000 v3 [1]. MODE_CTRL says the same as
your reading, though: 0x421 has SGMII_MODE (bit 10) set and 0x821 has
SGPLUS_MODE (bit 11). So the hand-over is SGMII either way, and 0x70 in
MISC2 is just not what tells it. On his board, MISC2 reads 0x70 after
the boot loader's block reset when U-Boot runs no network command, and
0x30 after a U-Boot ping.

Reboot loop on our OpenWrt tree (6.18, dwmac-ipq5018 + qca-uniphy), with
the OpenWrt ordering patch removed in both images. A boot counts as
broken on ping loss to a host on lan1, or FCS errors or PAUSE frames on
CPU port 6.

- Without your commit: 2 of 15 broken.
  - In one, the switch sent PAUSE frames to the CPU (1368 on port 6) and
    to lan1, and almost nothing got through. No FCS errors.
  - In the other, frames from lan1 reached the CPU, but nothing from the
    CPU went out on lan1, although port 6 ifInOctets kept counting. No
    FCS errors, no PAUSE frames.
  In our tree the conduit is closed and opened again at about 26 s
  (pcs_config() runs again, the UNIPHY already in SGMII+), and that
  didn't cure either boot. This fits your note that a re-sequence on the
  SoC side does not help.

- With your commit: 0 of 23 broken (20 reboots, 3 power cycles). The
  preconfig puts the UNIPHY in SGMII+ at about 2.1 s, 3.2-3.3 s before
  the switch configures its port, and pcs_config() at open finds the
  mode already set.

2 of 15 against 0 of 23 is weak on its own, but it points the same way
as your 18 of 51 against 0 of 32. In the same thread [1], FlyFish-go ran
the RC3000 v3 (RTL8367S, family C) at 2500base-x with only the OpenWrt
ordering patch removed: 4 of 7 cold boots broken, against 0 of 5 with
it. In every broken boot the SoC-to-switch direction was the one that
failed.

I have put the same result on your OpenWrt PR [2].

Tested-by: Stanislaw Pal <kuncy7@xxxxxxxxx> # Archer AX55 v1

[1] https://github.com/kuncy7/openwrt-nss-edma/pull/73#issuecomment-6796451511
[2] https://github.com/openwrt/openwrt/pull/26597

Best regards,
Stanislaw