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

[gabon pivovich]

On Tue, Nov 10, 2026 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+
[...]
> Oleg, if the AX55 can take it, a reboot loop with that commit and
> without patch 8 would settle this.

Hi Johan, Mieczyslaw, Alvin,

I tested this on my Archer AX55 v1 (IPQ5018 + RTL8367S-VB, family D,
CPU port 6 at 2500base-x, booting from NAND).

Tree: OpenWrt main (24c13d794c) with the family D series from
PR #19644 (v10-pre4), without the re-latch patch and without the
conduit ordering patch, plus your commit 50e49862d2ba on top.

MISC2 register:
- In U-Boot (stock TP-Link bootloader): 0x70, so the bootloader hands
  the UNIPHY over in SGMII here too.
- In Linux with your commit it reads 0x50 already in preinit. I could
  not catch the state before the first open from Linux, because
  OpenWrt preinit brings eth0 up at about 7.0 s.

Timing in the log: the switch configures its CPU port at about 4.86 s,
eth0 at about 7.0 s, the same two second gap you described.

Reboot loop: 16 boots, 16 good, 0 broken. On every boot the router
pinged a PC on a LAN port, the switch CPU port counted received
octets, and FCS and symbol errors stayed at 0.

I did not run the same loop on this tree without your commit.

Tested-by: Oleg Gavrilov <gabonpivovich@xxxxxxxxx> # Archer AX55 v1, RTL8367S-VB

Best regards,
Oleg


ср, 11 нояб. 2026 г. в 18:22, Stanislaw Pal <kuncy7@xxxxxxxxx>:
>
> 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