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

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

[Johan Alvarado]

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.

Patch 1 adds the SerDes indirect access helpers and SGMII (1 Gbps)
support. Patch 2 extends this to HSGMII (2.5 Gbps), which phylink
represents as 2500base-x.

Tested on a Mercusys MR80X v2.20 (RTL8367S wired to the SoC over the
SerDes), in both SGMII and HSGMII modes with a fixed-link device tree
description: link bring-up verified across cold boots, warm reboots,
module reloads and link down/up cycles, with sustained traffic and no
CRC/symbol errors. The HSGMII link is confirmed running at 2.5G at the
register level (SoC uniphy mode and gmac clocks); per-direction
throughput could not be pushed past ~1 Gbps on this board because the
SoC side is driven by the IPQ5018 SSDK and the user-facing PHY is 1G,
so full 2.5G line-rate throughput remains unverified on my hardware.

Signed-off-by: Johan Alvarado <contact@c127.dev>
---
v3:
  - Drop the DW8051 firmware loading entirely. Analysis of the vendor
    firmware showed it only duplicates the link management phylink
    already does; the one needed action (SerDes data-path reset via
    the BMCR register) is now performed directly in the driver, with
    the DW8051 kept disabled. This removes the dependency on the
    rtl8367s-sgmii.bin firmware blob, which could not be redistributed
    via linux-firmware (the GPL vendor source ships it as a byte array
    without the corresponding microcode source). Thanks to Luiz Angelo
    Daros de Luca for the firmware analysis.
v2: https://lore.kernel.org/netdev/0100019eb0b1822e-ffc5626c-1b9f-4c8a-8a1a-759a9e665f4f-000000@email.amazonses.com/
  - No code changes; resend because the SMTP provider used for v1
    corrupted the mails and patch 1/2 never reached the list.
v1: https://lore.kernel.org/netdev/aebccaad-eca3-4ea4-99dd-ae7edbc8981b@smtp-relay.sendinblue.com/

Johan Alvarado (2):
  net: dsa: realtek: rtl8365mb: add SGMII support for RTL8367S
  net: dsa: realtek: rtl8365mb: add HSGMII support for RTL8367S

 drivers/net/dsa/realtek/rtl8365mb.c | 336 +++++++++++++++++++++++++++-
 1 file changed, 332 insertions(+), 4 deletions(-)


base-commit: 8f4695fb67b259b2cae0be1eef55859bfc559058
-- 
2.54.0

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

[Mieczyslaw Nalewaj]

The fix applies not only to the RTL8367S but also to the RTL8367SB.

On 6/14/2026 1:21 AM, 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.
> 
> Patch 1 adds the SerDes indirect access helpers and SGMII (1 Gbps)
> support. Patch 2 extends this to HSGMII (2.5 Gbps), which phylink
> represents as 2500base-x.
> 
> Tested on a Mercusys MR80X v2.20 (RTL8367S wired to the SoC over the
> SerDes), in both SGMII and HSGMII modes with a fixed-link device tree
> description: link bring-up verified across cold boots, warm reboots,
> module reloads and link down/up cycles, with sustained traffic and no
> CRC/symbol errors. The HSGMII link is confirmed running at 2.5G at the
> register level (SoC uniphy mode and gmac clocks); per-direction
> throughput could not be pushed past ~1 Gbps on this board because the
> SoC side is driven by the IPQ5018 SSDK and the user-facing PHY is 1G,
> so full 2.5G line-rate throughput remains unverified on my hardware.
> 
> Signed-off-by: Johan Alvarado <contact@c127.dev>
> ---
> v3:
>   - Drop the DW8051 firmware loading entirely. Analysis of the vendor
>     firmware showed it only duplicates the link management phylink
>     already does; the one needed action (SerDes data-path reset via
>     the BMCR register) is now performed directly in the driver, with
>     the DW8051 kept disabled. This removes the dependency on the
>     rtl8367s-sgmii.bin firmware blob, which could not be redistributed
>     via linux-firmware (the GPL vendor source ships it as a byte array
>     without the corresponding microcode source). Thanks to Luiz Angelo
>     Daros de Luca for the firmware analysis.
> v2: https://lore.kernel.org/netdev/0100019eb0b1822e-ffc5626c-1b9f-4c8a-8a1a-759a9e665f4f-000000@email.amazonses.com/
>   - No code changes; resend because the SMTP provider used for v1
>     corrupted the mails and patch 1/2 never reached the list.
> v1: https://lore.kernel.org/netdev/aebccaad-eca3-4ea4-99dd-ae7edbc8981b@smtp-relay.sendinblue.com/
> 
> Johan Alvarado (2):
>   net: dsa: realtek: rtl8365mb: add SGMII support for RTL8367S
>   net: dsa: realtek: rtl8365mb: add HSGMII support for RTL8367S
> 
>  drivers/net/dsa/realtek/rtl8365mb.c | 336 +++++++++++++++++++++++++++-
>  1 file changed, 332 insertions(+), 4 deletions(-)
> 
> 
> base-commit: 8f4695fb67b259b2cae0be1eef55859bfc559058