* Question: net: phy: realtek: RTL8211FS SGMII bridge mode support
@ 2026-07-09 3:52 Jacky Huang
2026-07-09 9:57 ` Maxime Chevallier
0 siblings, 1 reply; 3+ messages in thread
From: Jacky Huang @ 2026-07-09 3:52 UTC (permalink / raw)
To: Andrew Lunn, Heiner Kallweit
Cc: Russell King, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Daniel Golle, Vladimir Oltean, netdev, linux-kernel
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.
Thanks,
Jacky C. Huang
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Question: net: phy: realtek: RTL8211FS SGMII bridge mode support
2026-07-09 3:52 Question: net: phy: realtek: RTL8211FS SGMII bridge mode support Jacky Huang
@ 2026-07-09 9:57 ` Maxime Chevallier
2026-07-10 14:17 ` Jacky Huang
0 siblings, 1 reply; 3+ messages in thread
From: Maxime Chevallier @ 2026-07-09 9:57 UTC (permalink / raw)
To: Jacky Huang, Andrew Lunn, Heiner Kallweit
Cc: Russell King, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Daniel Golle, Vladimir Oltean, netdev, linux-kernel
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
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: Question: net: phy: realtek: RTL8211FS SGMII bridge mode support
2026-07-09 9:57 ` Maxime Chevallier
@ 2026-07-10 14:17 ` Jacky Huang
0 siblings, 0 replies; 3+ messages in thread
From: Jacky Huang @ 2026-07-10 14:17 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Jacky Huang, Andrew Lunn, Heiner Kallweit, Russell King,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Daniel Golle, Vladimir Oltean, netdev, linux-kernel
Hi Maxime,
Thanks for the feedback! I had not considered the SFP or additional PHY case
before.
The hardware we plan to support has the SGMII side permanently connected to
an Ethernet switch.
MAC - RGMII - RTL8211FS - SGMII - Ethernet switch
The switch is initialized from a configuration EEPROM. There is no SFP or
separate PHY on the SGMII link.
I will take another look at how the SGMII-side status and in-band aneg should
be handled.
In addition, after reviewing the board-level strap design, I found that the
intended mode may not always be selected reliably, so I still need to consider
a strap-override flow.
Thanks again,
Jacky
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-07-10 14:18 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-07-09 3:52 Question: net: phy: realtek: RTL8211FS SGMII bridge mode support Jacky Huang
2026-07-09 9:57 ` Maxime Chevallier
2026-07-10 14:17 ` Jacky Huang
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox