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

[Johan Alvarado]

Hi Mieczyslaw,

On 7/10/2026 9:23 AM, Mieczyslaw Nalewaj wrote:

[...]

> 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.

I considered this, but I don't think the CPU port is the right
condition here. Whether the limiter needs raising depends on the
port's attainable line rate, not on its CPU role: the reset default
of 0x1FFFF (~1.048 Gbps) only becomes a bottleneck on a port that can
run faster than that, and in this switch family the only such port is
the SerDes-backed external interface (physical port 6) in HSGMII
mode. The other external interfaces are MII/TMII/RMII/RGMII, which
top out at 1 Gbps, below the reset default - the limiter cannot
engage there, so a system with its CPU port on port 7 already works
today without any write.

A CPU-port condition would also miss the opposite case: if the SerDes
port were ever used as a non-CPU port (say, a 2.5 Gbps cascade to
another switch), it would still need the limiters raised, but a loop
over CPU ports would skip it.

This also matches the vendor driver's behavior: its switch init
raises the ingress and egress limiters unconditionally, and only for
the SerDes-capable external interface (physical port 6). It never
touches the port 7 limiters and never conditions any of this on which
port faces the CPU. Physical port 5 does not host an external
interface in this family at all, so there is no system with a CPU
port there.

On the driver side, every chip in rtl8365mb_chip_infos declares
SGMII/HSGMII only on external interface 1 / port 6 (the SerDes mux
only routes there), which is why the series keys the write on
mb->sds_supported and the fixed SerDes port. That gating also keeps
the QoS registers of the chips without a usable SerDes
(RTL8365MB-VC, RTL8367RB-VB) completely untouched, which I would
rather not change without a functional reason.

If a chip with SGMII/HSGMII on a different port is ever added, it
will need its own chip_info entry and SerDes bring-up work anyway,
and support for its rate limiters can be added then.

Regards,
Johan