Lynx 10G SerDes Driver on my kernel

[Tanjeff Moos]

Hi Vladimir,

Am 02.12.25 um 17:29 schrieb Vladimir Oltean:
> Hi Tanjeff,
> 
> On Tue, Dec 02, 2025 at 12:12:26PM +0100, Tanjeff Moos wrote:
>> Hello Vladimir,
>>
>> I want to use your Lynx 10G SerDes driver (plus fman and fsl_guts) on
>> our OpenWRT kernel (6.6.110) and don't know how to integrate it properly.
>>
>> I only found the driver in the NXP kernel[1]. Did you send patch to a
>> linux kernel mailing list that I may apply?
>>
>> Kind regards, Tanjeff
>>
>>
>> [1] https://github.com/nxp-imx/linux-imx.git
>>
> 
> (I'm unsure why you CCed linux-phy, but OK)
> 
> Picking the right base kernel seems to be of utmost importance. From
> what I know, OpenWRT maintain their own kernel version and don't use
> vendor kernels (they import patches from vendor kernels as .patch files,
> however).
> 
> I see this commit in OpenWRT:
> 
> commit 6942ca412124a1f322e19e2289a59ed8e27b9c24
> Author: Pawel Dembicki <paweldembicki at gmail.com>
> Date:   Sat Nov 1 23:36:36 2025 +0100
> 
>      layerscape: switch to Linux 6.12
> 
>      Linux 6.12 has been validated on Layerscape platforms, including NXP
>      reference boards and multiple custom designs. Tests covered system
>      boot, networking, storage, and common peripherals, with no regressions
>      observed.
> 
>      Enable 6.12 as the default to continue broader testing and integration.
> 
>      Signed-off-by: Pawel Dembicki <paweldembicki at gmail.com>
>      Link: https://github.com/openwrt/openwrt/pull/20614
>      Signed-off-by: Christian Marangi <ansuelsmth at gmail.com>
This commit is on the main branch, but not on a release branch. We base 
our OpenWRT build on the stable version v24.10.4, which still uses 
kernel v6.6 for layerscape.

Nevertheless I will consider updating the kernel.

> To integrate the Lynx 10G driver, you'll need to do that on your own as
> patches. The correct git tree used by Layerscape boards in Linux Factory is:
> https://github.com/nxp-qoriq/linux/tree/lf-6.12.34-2.1.0
>
> My strong recommendation, assuming you want something stable, is to
> integrate the NXP Linux Factory patches, which you'll receive some
> official NXP support for.
> 
> The rest of the email is just for the sake of full transparency. I will
> be talking about my development work, which I strongly recommend that
> you do not integrate into OpenWrt at this stage.
> 
> The SerDes patches (both for the 10G and the 28G Lynx) are being
> constantly reworked in an attempt to get as much upstream as possible.
> Since the 10G and the 28G Lynx SerDes blocks are very similar, they
> should share a lot of code. For that reason, adding a new driver for the
> 10G Lynx depends on some changes being made in the 28G Lynx.
> 
> I am keeping a personal development branch on top of linux-next here:
> https://github.com/vladimiroltean/linux/commits/net-phy-upstreaming
> *However* I modify it frequently, *and* I only retest those
> modifications rigorously when I need to (i.e. when I need to submit some
> patches upstream). I am doing this because any time I am making a change
> as a result of a review comment, it has to propagate during rebase like
> a shock wave through a huge stack of dishes.
> 
> So if you pick up the patches from this branch today, there is no
> guarantee you will find them in the same state next week.
> 
> The bottleneck is on the patches being accepted into linux-phy.
> Currently a group of 15 patches from this development branch have been
> submitted to the mailing list a week ago:
> https://lore.kernel.org/linux-phy/20251125114847.804961-1-vladimir.oltean@nxp.com/
> and that's about it. There are 22 more linux-phy patches on top of that
> to be accepted until mainline gains some support for the 10G Lynx. And
> that isn't considering:
> - device trees, which are also waiting for the acceptance of the driver
> - networking consumer driver changes (I'm moving SerDes handling into
>    the Lynx PCS driver, in order for not just dpaa-eth to benefit from
>    it, but also enetc, felix, dpaa2)
> 
> Out of curiosity, for what platform and what use case do you need the patches?
We build WLAN access points for railway (i.e. passenger WLAN). We design 
the hardware ourselves. Older models are still based on PowerPC QorIQ 
(T1024 and others), but the most recent model uses a Layerscape LS1046A. 
This is the one I work with.

We use OpenWRT with our own additions. We build binary images for all 
devices (PowerPC and ARM) from the same OpenWRT tree, using different 
configuration files. Currently, all devices use the same kernel version 
(v6.6.110 + OpenWRT patches + our patches).

Speaking of the device I'm working with, we connected two Broadcom 
BCM84891L PHYs (100M / 1G / 2.5G / 5G / 10G) to MAC9 and MAC10. The PHY 
supports different protocols for different speeds. The only protocol 
supporting all speeds is USXGMII, but this is not supported by LS1046A. 
Therefore we use SGMII (for 100M / 1G), 2500Base-X (for 2.5G) and XFI 
(for 2.5G / 5G / 10G). Yes, we use different protocols for 2.5G; see below.

So far I didn't manage to switch the LS1046A SerDes between SGMII and 
XFI protocols without changing the RCW. However, I can switch between 
SGMII and 2500Base-X at runtime. Therefore we provide different variants 
of the device:

- "Slow" Ethernet (100M / 1G / 2.5G), switching between SGMII and
   2500Base-X at runtime. Here we use the BCM54991L PHY (only up to 2.5G,
   otherwise identical), but this is not relevant for my problem.

- "Fast" Ethernet (2.5G / 5G / 10G), using XFI + rate limiting in the
   MAC.

I patched fman and fman_memac to alter SerDes settings when the PHY 
reports speed changes. This is rude, but worked...

I created the patches for kernel 5.15.167, and they do not apply on 
v6.6.110. Instead of reworking my patch, I'd rather use your work, which 
is much cleaner. Also I hope that it supports switching between SGMII 
and XFI, which would allow our "fast" variant to support all speeds from 
100M to 10G.