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

[Stanislaw <kuncy7@gmail.com>]

Hi Luiz, Johan, Mieczyslaw,

Resolved, and it was not the driver: the cold-start trunk failure on my
Archer AX55 v1 was a failing power supply. Apologies for the noise, and
thanks for the time you all put into it.

The A/B/A that settles it, same image throughout (v6 series, no
busy-wait, no 0x060C writes, no pre-init delay), same ~10 h power-off:

  old PSU  -> bad on every cold morning (4 documented occurrences)
  new PSU  -> clean, twice (including a 10 h soak)
  old PSU again -> bad again, last night

The last line is the one that matters: putting the old supply back
reproduced the exact same signature - link up at 2.5G/Full, no CRC or
symbol errors on the link, but 326 FCS errors and 326 drop events on
the switch's CPU-facing port, nothing reaching the WAN wire, and the
switch->CPU direction byte-exact clean. Only the switch's SerDes
receiver is affected, and only until the chip is fully re-initialised.

In hindsight the earlier evidence fits: the 180 s pre-init delay
"fixed" it because it gave the supply three minutes to come up, short
power-cycles never reproduced it because the capacitors had no time to
discharge, and a driver re-probe cured it because... well, see below.

> Another test would be to dump all switch regs before the first reset
> and compare what is different from the state after the reset.

Done, via the regmap debugfs. The SerDes-related configuration is
byte-identical between the bad state and the healthy one afterwards:

  SDS_MISC (0x1d11)      bad 0x1f00   good 0x1f00
  SDS_OPTION (0x13c0/c1) bad 0x0000   good 0x0000
  ext-if mode (0x1311)   bad 0x1016   good 0x1016
  MISC_CFG0 (0x130c)     bad 0x0043   good 0x0043

So the driver programs the chip identically in both cases; the failure
is not visible in the register state at all. (The rest of the dump does
differ, but that is counters and statistics, and the "good" dump was
taken after the reset experiments below, so I would not read anything
into it.)

> I would expect the CHIP_RST (bit 0) to clear everything, but you
> never know...

Also done, on the bad state, in the order SDS -> DW8051 -> NIC -> GPH
-> CFG -> SW -> CHIP:

  SDS_RST, DW8051_RST, NIC_RST, GPH_RST: no change at all, the FCS
  error count stays exactly where it was and the trunk stays dead.

  CFG_RST, SW_RST, CHIP_RST: inconclusive. The counters go to zero, but
  so does the switch configuration, so the trunk cannot pass traffic
  afterwards for reasons that have nothing to do with the fault. I
  cannot tell from this whether the datapath was repaired.

  Full driver re-probe (reset + complete re-init): cures it, as always.

The useful half is the first line: none of the resets that leave the
configuration intact repairs the datapath. Whatever the marginal supply
does to that receiver, only a complete re-initialisation clears it -
which is consistent with the register dump showing no difference to
repair in the first place.

I will run one more cold soak tomorrow morning, back on the new supply,
to confirm the A/B/A closes cleanly rather than resting on a single
good/bad pair. I will only write again if that result contradicts the
above.

Nothing here asks for a change to your series. If the maintainers want
a Tested-by for the RTL8367S HSGMII path on this board, it has been
carrying traffic reliably for days now on a healthy supply.

Best regards,
Stanislaw