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

[Johan Alvarado <contact@c127.dev>]

Hi Mieczyslaw,

On 7/16/2026 8:40 AM, Mieczyslaw Nalewaj wrote:

[...]

> For verification on real hardware:
>
> The SGMII/HSGMII link on RTL8367S (and compatible RTL8365MB-VC) can be
> intermittently unstable after cold boot, manifesting as egress stalls,
> CRC errors or complete packet loss on the SerDes-attached CPU port.
> This has been observed as a non-deterministic failure depending on the
> PLL lock state at power-on.

Where has this been observed? The RTL8365MB-VC cannot be affected:
it has no SGMII/HSGMII-capable external interface at all - its
external interfaces are MII/TMII/RMII/RGMII only, which is what the
driver's chip info table reflects.

The only cold boot observations reported against this series are
Stanisław's, and his results elsewhere in this thread now cover
exactly the two changes proposed here: a test image carrying both
the ~98 ms delay and the 0x060C-0x060F writes still came up with
the trunk degraded after a multi-hour power-off. What did recover
it, immediately and without a reboot, was a full re-probe of the
switch - the GPIO hardware reset plus the complete chip init -
while everything that resets only the SerDes left the bad state
in place. Whatever his unit is sensitive to after a long
power-off, it is not addressed by either proposed change, and it
lives in the full init sequence rather than in
rtl8365mb_pcs_config().

> Reverse-engineering of the vendor DW8051 firmware blob (Sgmii_Init[])
> shows that the vendor driver performs two critical steps after the
> SerDes data-path reset (BMCR DPRST_PHASE2) which were missing from the
> Linux driver:
>
> 1. A ~98 ms delay to let the SerDes PLL fully lock before any further
>    register access. The vendor firmware uses a timer interrupt to count
>    this delay; without it the analog front-end may still be settling.

The Sgmii_Init[] image shipped in the vendor's published U-Boot
sources for my board (1233 bytes, loaded into the 8051 through the
register window at 0xE000) does contain a one-shot startup wait
counted by the timer 0 interrupt: the ISR increments 16-bit tick
counters in the 8051's XDATA RAM, and the main flow busy-waits
until one of them reaches 98 (0x62), then latches a flag so the
wait never runs again.

But it sits on the other side of the data-path reset from where
your patch places it. The first thing the image does once the wait
expires is call the routine that performs the SerDes bring-up: the
un-reset (0x7106 to SerDes register 3 through the indirect access
registers), then the BMCR writes 0x1401 and 0x1403 - the same
data-path reset sequence Luiz described during the v2 review, which
pcs_config() already implements. Nothing in the image waits after
the BMCR writes. The wait is the firmware pacing its own startup
before it first touches the SerDes, which makes sense for an
autonomous microcontroller that the loader releases in the middle
of the bring-up; it is not a post-reset PLL lock delay.

> 2. Writing a "Local Jam Table" calibration vector to internal ASIC
>    registers 0x060C-0x060F (values 0x83, 0xAA, 0x7E, 0x80). These
>    registers configure the SerDes analog equalizer and DC-offset and
>    are not exposed through the normal SDS_INDACS window. Omitting them
>    leaves the analog front-end in an uncalibrated state.

Nothing in the image supports this:

- No instruction in the image addresses 0x060C-0x060F, by any
  addressing form: immediate DPTR load, split DPH/DPL load, or the
  register-pair arguments the image passes to its write helpers.

- The only XDATA accesses in that neighborhood are the image's own
  tick counters and flags at 0x0624-0x062C - the ones its timer ISR
  increments. That is plain 8051 work RAM, not switch registers.

- The byte sequence 0x83 0xAA 0x7E 0x80 occurs nowhere in the image
  as data, in either order. 0xAA and 0x7E appear only as immediate
  operands of register loads, and 0x83/0x80 only as bytes of the
  instruction stream. A reading of the byte stream that slips out
  of alignment with instruction boundaries could produce exactly
  such a list.

- In the switch register space - which is what your proposed
  regmap_write()s would actually hit - the vendor register headers
  name 0x060C-0x060F as the ACL rule template 3 control registers.
  The patch as posted would clobber an ACL template with values
  that mean nothing there, and would not touch the SerDes.

For the record, on my RTL8367S hardware running exactly this code,
the HSGMII trunk has been up for over a week carrying several
hundred gigabytes with zero CRC/FCS/symbol errors on every port,
and cold boots throughout the development of this series never
produced the instability described above.

So I don't think either change is supportable: the sleep is placed
where the firmware has none, the register writes target unrelated
ACL registers, and both have now been tested together on the
affected unit without improvement. For the same reasons I don't
expect a re-run of the cold-soak test with only these two changes
to tell us anything: the writes cannot reach the SerDes, and the
delay exists in the firmware only as a one-shot wait before the
data-path reset the driver already performs. Stanisław's unit
reproduces the bad state reliably, which makes it a good bench for
instrumenting the early init path; that investigation is follow-up
material rather than part of this series.

Best regards,
Johan