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

[Johan Alvarado]

> I think we don't need the firmware at all. Requesting a proprietary
> binary that we don't control to do things phylink already does is
> unnecessary and adds a burden to linux-firmware.
> I strongly suggest dropping rtl8365mb_dw8051_load_firmware() entirely,
> porting the BMCR reset sequence above directly into the driver, and
> keeping the 8051 disabled.

I tested exactly this on the MR80X v2: dropped the firmware loading,
ported the 0x1401/0x1403 BMCR sequence right after the SerDes reset
deassert, and kept the DW8051 permanently disabled (also removing the
re-enable at the end of the SGMII config path).

Results in both SGMII and HSGMII modes:

 - Link bring-up: 10/10 cold boots (power drained), 10/10 warm
   reboots, 10/10 module reload cycles (rmmod/insmod), and repeated
   ip link down/up — link came up cleanly every time.

 - Sustained traffic, CPU-generated (iperf3 on the router, 30 min
   each direction): ~750 Mbit/s in both modes, CPU-bound. Zero
   CRC/symbol errors in the port MIB counters.

 - NAT forwarding LAN->WAN (iperf3 between external hosts, 10-30 min
   runs): ~800-820 Mbit/s sustained, PHY-bound (1G user ports), again
   with zero CRC/symbol errors. A small number of buffer discards
   under sustained load (~0.07%), consistent with congestion rather
   than link-level corruption.

So I can confirm your analysis. v3 will drop the firmware entirely
and carry this with your Suggested-by.

> If we intend to support non-fixed links in the future (where in-band
> AN is required), we would need to implement phylink_pcs and
> pcs_get_state instead of just forcing the MAC. For fixed-link it is
> fine, but we should plan accordingly.

Agreed. I'd prefer to keep v3 scoped to fixed-link (matching what
RGMII supports today) and leave the phylink_pcs conversion for a
follow-up series.

Best regards,
Johan