Re: [PATCH net-next v5 0/2] net: dsa: realtek: rtl8365mb: add SGMII/HSGMII support for RTL8367S

[Mieczyslaw Nalewaj <namiltd@yahoo.com>]

On 7/9/2026 10:25 PM, Johan Alvarado wrote:
> The RTL8367S is a 5+2 port switch from the same family as the
> RTL8365MB-VC already supported by this driver. Its chip info table
> entry declares SGMII and HSGMII on external interface 1, but the
> driver so far only implements RGMII, leaving boards that wire the
> switch to the CPU over the SerDes without a working CPU port.
> 
> This series implements both modes. The configuration sequence and the
> SerDes tuning parameters are derived from the GPL-licensed Realtek
> rtl8367c vendor driver, as distributed in the Mercusys MR80X GPL code
> drop, and cross-checked against the real register sequence captured at
> runtime by chainloading a custom U-Boot ahead of the stock firmware
> and logging the live SerDes accesses on hardware.
> 
> The vendor driver brings up the SerDes by loading firmware into the
> switch's embedded DW8051 microcontroller. Analysis of that firmware
> (by Luiz Angelo Daros de Luca) showed it only performs a SerDes
> data-path reset right after the SerDes reset is deasserted, and then
> runs a link-polling loop that writes the external interface force
> registers -- duplicating, and racing with, the link management phylink
> already performs. This series therefore keeps the DW8051 disabled and
> performs the one necessary action (the data-path reset via the SerDes
> BMCR register) directly in the driver, avoiding both the race and a
> dependency on a redistributable firmware blob.
> 

[...]

> ---
> v5:
>   - Raise the port 6 ingress and egress rate limiters to their maximum
>     at setup time, as the vendor switch init does. The chip resets them
>     to 0x1FFFF (~1.048 Gbps in units of 8 Kbps), which caps the
>     aggregate HSGMII throughput at roughly 1 Gbps; the cap was
>     confirmed on an RTL8367S-based Mercusys MR85X, where raising the
>     limiters took multi-client throughput across the HSGMII CPU port
>     from ~1.02 Gbps combined to ~2 Gbps (link in patch 2). The related
>     HSGMII scheduler line rate (LINE_RATE_HSG_H) is already set to its
>     maximum by the common init jam table. Pointed out by Mieczyslaw
>     Nalewaj.

I think you should make limiter initiation dependent on whether
the port is assigned to CPU. In a loop, check if the port is CPU port
and set limiters for it. 
This way, newly added systems with CPU port 5 or 7 will also work.

Regards