Re: [PATCH net-next v6 1/2] net: dsa: realtek: rtl8365mb: add SGMII support for RTL8367S

[Stanislaw]

Hi,

I have been testing this series on a second RTL8367S board: a TP-Link
Archer AX55 v1, where the switch SerDes runs HSGMII (2500base-x) on
external interface 1 to an IPQ5018 gmac1 (stmmac, fixed-link), on an
OpenWrt 6.12 kernel. Some cold-boot results that may be relevant to the
calibration discussion.

Test image carried, on top of the v6 series:
 - the SDS indirect-access busy-wait fix, and
 - the ~98 ms PLL-settle delay plus the 0x060C-0x060F "Local Jam
   Table" analog calibration proposed in this thread.

Result: after the router sat powered off overnight (multi-hour cold
soak), the first boot still came up with the trunk degraded - in this
run completely dead. The switch reported link up (2.5G/Full), no
CRC/symbol error counters moving, but dot1dTpPortInDiscards climbing
on the CPU-facing port, and the WAN never got a DHCP lease (ping:
sendto: Network unreachable). Milder runs of the same state show
55-70 % packet loss with sub-ms RTT on the frames that do pass. So on
this board the analog calibration, like the BMCR data-path reset and
the busy-wait before it, does not prevent the cold-start bad state.

What does cure it, without a reboot: a full driver re-probe. Unbinding
and re-binding the switch device re-runs the whole probe path - the
GPIO hardware reset of the RTL8367S plus the complete chip init (all
jam tables) - and the trunk comes back clean immediately:

  ----- BEFORE: ping upstream router
  ping: sendto: Network unreachable
  ----- BEFORE: CPU port discards
  dot1dTpPortInDiscards: 17 (climbing)
  ===== echo <dev> > .../unbind ; echo <dev> > .../bind =====
  ... wan: Link is Up - 1Gbps/Full - flow control rx/tx
  ----- AFTER: ping upstream router
  20 packets transmitted, 20 received, 0% packet loss

A soft reboot fixes it the same way (sometimes on the second try).
Short power-cycles (~1 min off) do not reproduce it; only a multi-hour
cold soak does. Anything that resets the SerDes without the full chip
re-init (BMCR data-path reset, repeated reset pulses) leaves the bad
state in place - one variant I tried even reports the port healthy
after a reset pulse while the datapath keeps mangling frames.

To me this points away from the SerDes analog front-end tuning values:
the first full init on cold silicon lands the chip in a bad state, and
a repeated full init clears it, hours later, with the silicon warm or
cold. That looks more like an ordering/settling problem in the early
init sequence than like the calibration vector itself.

On the hardware-health question raised elsewhere: the board looks
clean, no bulging/dried capacitors, and the 3.3 V and 1.8 V rails
measure correct. But this is a single unit, so I cannot rule out a
marginal sample - the cold-soak state does reproduce reliably here
every morning, which at least makes it a good test bench.

Happy to test any patch or instrumented build on this hardware.

Best regards,
Stanislaw