Lynx 10G SerDes Driver on my kernel

[Vladimir Oltean]

On Thu, Dec 04, 2025 at 08:01:10PM +0100, Tanjeff Moos wrote:
> For clarity, I like to re-state my PLL configuration:
> 
> - "slow" devices:
>   - RCW[SRDS_PRTCL_S1] = 0x2233
>   - RCW[SRDS_PLL_REF_CLK_SEL_S1] = 0b11
>   - PLL 1:     5 GHz (derived from external 125 MHz)
>   - PLL 2: 3.125 GHz (derived from external 156.25 MHz)
> 
> - "fast" devices:
>   - RCW[SRDS_PRTCL_S1] = 0x1133
>   - RCW[SRDS_PLL_REF_CLK_SEL_S1] = 0b11
>   - PLL 1:       5 GHz (derived from external 125 MHz)
>   - PLL 2: 5.15625 GHz (derived from external 156.25 MHz)
> 
> My patch never reconfigures the PLLs or their clock net frequencies. It 
> assigns lanes to PLL 1 (for SGMII) or PLL 2 (for 2.5SGMII). This is only
> done on "slow" devices. The "fast" devices always use XFI (PLL 2).

And the lynx-10g kernel driver does the same as your patch, plus more
(below).

> > In Linux we don't change the PLL refclk and clock net selection that was
> > made by the RCW. Doing so would mean powering down all lanes that use
> > that PLL, and unbinding and rebinding the Ethernet driver (because the
> > supported_interfaces mask will change, and the phylink instances need to
> > be destroyed and re-created to pick up that change). It is a very
> > invasive operation.
> The lynx-10g driver seems to alter PLL assignment in lynx_10g_lane_set_pll().

Yes.

> That means that a lane could be operated in SGMII or 2.5SGMII mode by assigning
> the correct PLL (given that the PLLs are properly pre-configured via RCW).

Yes.

> But it also means that in theory I could configure PLL1 = 5 GHz and PLL2 = 5.15625 GHz
> and then switch between SGMII (100M/1G) and XFI (2.5G / 5G / 10G via rate limiting).
> This way all media speeds would be possible.

Yes.

> However, switching to another PLL isn't enough, I also have to switch the lane's protocol.

Yes.

> This worked for SGMII and 2.5SGMII, but I never managed to switch between SGMII to XFI.

Yes, the SoC architecture on devices with the 10G Lynx didn't initially
target the use case of switching between SGMII and XFI, so you won't find
documentation on how to do that. We've since validated that the use case
works on LS1088A, LS2088A and LS1046A by implementing a procedure called
"RCW override", where you use undocumented SoC features in drivers/soc/fsl/guts.c
to essentially change the RCW[SRDS_PRTCL_S1] value to something different
than what was originally loaded at boot time. We've tested the feature
on the above SoCs and it is seamlessly integrated in the lynx-10g driver
(it is not invasive, the user is essentially unaware that this is taking
place).

As mentioned earlier, lynx-10g is in our upstreaming queue, but it may
take a while to reach it. You can get the driver with the RCW override
support from Linux Factory, though.

> >>> You are just requesting to support the 10G, 5G and 2.5G media speeds via
> >>> LANE_MODE_10GBASER (with pause-based rate adaptation in the Ethernet PHY),
> >>> and the 1G and 100M media speeds via LANE_MODE_1000BASEX_SGMII.
> >>
> >> Yes, that is my minimum target. I hoped that the "fast" device can support
> >> all speeds, but it's not mandatory.
> > 
> > What do you mean "can support all speeds", do you mean the media side
> > speeds?
> Yes, indeed.
> 
> > By switching from 10GBase-R to SGMII it would support them all,
> > wouldn't it?
> I don't think so. SGMII does only support 100M and 1G. Tell me if I'm wrong.

I hope I didn't confuse you by naming XFI "10GBase-R". This is what the
10GbE SerDes protocol should truly be called - XFI is the name of an
electrical standard.

All I meant to say here was that by using XFI for the >1G media speeds
and SGMII for the <=1G ones, and dynamically switching SerDes protocols
each time your Broadcom PHY changes phydev->interface as a result of a
media side auto-negotiation process, you should be able to support them
all. Basically, the lynx_pcs_config() function, called by phylink on
major protocol reconfig paths, calls phy_set_mode_ext(lynx->serdes[i],
PHY_MODE_ETHERNET, ifmode), and this is what triggers the SerDes
protocol change.