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

[Stanislaw]

Hi Luiz,

Two updates from the bench: last night's cold-soak result, and a
correction about the reset GPIO.

1) A 3-minute pre-init wait PREVENTS the bad state.

Last night's image carried a plain msleep(180000) at the top of
rtl83xx_probe(), before anything touches the chip - and nothing else
on top of the v6 series (no busy-wait, no 0x060C writes). After ~10 h
powered off, the first init landed clean for the first time: 0 FCS
errors on the SerDes CPU port, 0 drop events, DHCP lease right away,
0% loss on the trunk. Every comparable soak before (same hardware,
overnight off, no wait) came up degraded. Single morning so far - I
will repeat it - but this is the first thing that has *prevented* the
state rather than cured it after the fact.

During those 180 s the chip is powered and out of its (bus-level)
reset, just untouched by the driver. So your time-vs-state
discriminator leans "time": the very same init sequence that lands
bad when run at t=3.5 s lands clean when run at t=187 s. It does not
fully separate "the switch needs time" from "something else on the
board needs time", but nothing else shows any distress at t=3.5 s -
the SoC-side MAC/PCS come up fine, and even in the bad state the
switch's transmit direction is byte-exact clean.

2) Correction: the realtek driver performs NO hard reset here.

I mis-stated this earlier: reset-gpios on this board sits on the MDIO
*bus* node (the IPQ5018 MDIO bus driver toggles it once at bus init),
not on the switch node. rtl83xx_probe() therefore sees neither
reset_ctl nor a reset gpio and the hard-reset branch never runs - I
confirmed it with a print inside that branch. So the curing re-probe
is a pure *soft* full init (detect + complete setup/jam-table
sequence, the only chip reset being the soft one in setup), no pin
involved. The "double reset in probe" scenario does not apply on this
board at all.

3) Next steps, along your suggestions:

- Bisect the required off-time with the no-wait image, to get
  reproductions on demand instead of one per night.
- On the next on-demand bad state: full register dump via regmap
  debugfs, bad state vs. post-cure, plus the reset-bit isolation.
- Then bisect the wait itself (180 s -> 90 -> 45 ...) to find the
  threshold - that number should hint at which physical process we
  are waiting out.

Best regards,
Stanislaw