Re: Question: net: phy: realtek: RTL8211FS SGMII bridge mode support

[Maxime Chevallier]

Hi,

On 7/9/26 05:52, Jacky Huang wrote:
> Hi,
> 
> RTL8211FS is the SGMII-capable variant of RTL8211F. Besides the standard
> copper/RGMII mode, it supports hardware-strapped RGMII-to-SGMII bridge mode,
> where the MAC side uses RGMII and the line side uses SGMII.
> 
> The in-tree realtek driver currently does not handle this mode. RTL8211FS
> shares the same PHY ID as RTL8211F (0x001cc916), so the driver binds it
> as a standard RTL8211F and follows the existing copper/RGMII path. In
> RGMII-to-SGMII bridge mode, this means read_status() does not observe the
> SGMII-side link and the link stays down.
> 
> We have discussed this with Realtek. They confirmed that the current mode
> can be detected from a vendor mode-selection register shared by RTL8211F
> variants, and that this case is application-dependent rather than generic
> copper PHY behavior.
> 
> Our plan is to add RTL8211FS bridge mode support inside the realtek
> driver, gated on the detected mode. The driver would only read this
> register for detection and would not use it to override the hardware
> strapping. For that mode, config_init() would program the SGMII side as
> needed, and read_status() would read the SGMII-side link status instead
> of relying on the copper path. The existing RTL8211F copper/RGMII behavior
> would be left unchanged.
> 
> Does this approach sound acceptable for upstream? If you prefer a
> different model, or if there is already related work that we should build
> on, please let me know.

If you can tell the mode based on the straps, that's OK :) There are other drivers
that do the same, for example the TI dp83869 (it's not based on a strap value,
but rather a custom DT property, but it's the same idea), or some broadcom
drivers that read strap state from registers and switch to fiber mode.

What's missing is proper support for what comes after the SGMII bridge, if you
have an SFP after for example, there's all the plumbing to support handling that
SFP module, however there's no way (yet) to handle the PHY within that module,
as you'll have :

MAC - RGMII - PHY - SGMII - PHY
                             ^
                             |
     nothing handles the state machine of that
     one PHY

If you have a DSA switch on that SGMII link though, it may "just work" as long as
you correctly read the status and configure inband aned on the SGMII side.

Maxime