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

[Luiz Angelo Daros de Luca]

> Hi Luiz, Mieczyslaw,
>
> > Stanislaw, do you have a reset pin or a reset controller configured?
>
> Yes - a reset GPIO, no reset controller:
>
>   reset-gpios = <&tlmm 33 GPIO_ACTIVE_LOW>;
>
> on the switch node. So on this board the probe path does run both
> resets: the GPIO hard reset from rtl83xx_probe() plus the soft reset
> during setup. That is worth stressing, because the re-probe that cures
> the cold-soak state performs *exactly the same sequence* - same GPIO
> reset, same soft reset, same full init - as the probe that lands in
> the bad state. The only difference is that it is the second run. So
> it does not look like a missing reset; more like something about the
> very first init pass on cold silicon.

That might eliminate the cause as the sw reset being less effective.

> On "loading too early": the driver is a module here and probes ~20 s
> after power-on (rootfs mount), so the rails have long been up by then.
> That said, 20 s of a cold board is a different thermal/electrical
> state than the same board a minute after a reboot, and short
> power-cycles (~1 min) never reproduce the issue - only a multi-hour
> soak does.

When I said too early, I meant other components that interact with the
switch. Maybe they are not ready. Try to skip the module loading
during boot and load it a minute (or more) later. If it works, we have
an indication that is not the switch.

> Next cold morning I'll do the reset-bit isolation on the degraded
> state, per Luiz's map, before falling back to the full re-probe.

Another test would be to dump all switch regs before the first reset
and compare what is different from the state after the reset. Maybe
depending on the previous switch state, it may require more time to
recover from reset. I suggest the regmap debugfs.

If the double probe works, you can also incrementally duplicate the
process until you reach the point where it works. My 2-cent guess is
the eee reg set by the jam table. And you could also add some sleeps
to check if it is time related or just state related. This is
fundamental to track the issue (state or time related).

It would also be great if you could isolate how long you have to keep
the device off to reproduce the issue. Try a simple binary search.
Reducing this test window will speed up the tests.

Regards,


> Best regards,
> Stanislaw