Re: [PATCH phy-next 5/5] phy: lynx-28g: add support for 25GBASER
From: Josua Mayer
Date: Wed May 13 2026 - 07:46:33 EST
Am 13.05.26 um 13:37 schrieb Josua Mayer:
> Am 11.05.26 um 17:00 schrieb Vladimir Oltean:
>> From: Ioana Ciornei <ioana.ciornei@xxxxxxx>
>>
>> Add support for 25GBASE-R in the Lynx 28G SerDes PHY driver. This will
>> be used by the dpaa2-mac consumer on LX2160A with:
>> - phy_validate(phy, PHY_MODE_ETHERNET, PHY_INTERFACE_MODE_25GBASER) to
>> detect support.
>> - phy_set_mode_ext(phy, PHY_MODE_ETHERNET, PHY_INTERFACE_MODE_25GBASER)
>> to reconfigure the lane for this protocol.
>>
>> The intended use case for dynamic protocol switching to 25GBase-R is
>> with SFP28 modules, and protocol switching is triggered by the SFP
>> module insertion. There also exists a 25GBase-KR use case, where the
>> protocol switching is covered by IEEE 802.3 clause 73 auto-negotiation.
>> However, that is not handled here; it merely needs the support added
>> here as basic ground work.
>>
>> The lane frequency for 25GbE is sourced from a clock net frequency of
>> 12.890625 GHz, as produced by PLLF or PLLS, further multiplied by the
>> lane by 2. The clock net frequencies produced by the PLLs are treated as
>> read-only by the driver, so the absence of a PLL provisioned for the
>> right clock net frequency implies absence of 25GbE support, even though
>> a lane might have the appropriate protocol converter for it.
>>
>> In terms of implementation, the change consists of:
>> - determining at probe time if any PLL was preconfigured for the
>> required clock net frequency for 25GbE
>> - adding the default lane parameters for reconfiguring a lane to 25GbE
>> irrespective of the original protocol
>> - allowing this operating mode only on supported lanes, i.e. all lanes
>> of LX2162A SerDes #1, and LX2160A SerDes lanes 0-1, 4-7.
>>
>> Signed-off-by: Ioana Ciornei <ioana.ciornei@xxxxxxx>
>> Signed-off-by: Vladimir Oltean <vladimir.oltean@xxxxxxx>
>> ---
>> Change previously submitted at:
>> https://lore.kernel.org/linux-phy/20260114152111.625350-6-vladimir.oltean@xxxxxxx/
>>
>> Changes:
>> - reword commit message
>> ---
>> drivers/phy/freescale/phy-fsl-lynx-28g.c | 90 +++++++++++++++++++++++-
>> 1 file changed, 88 insertions(+), 2 deletions(-)
> In order to test this patch with 25Gbps link, additional changes on other drivers are needed.
> This is not a short-coming of this patch.
>
> 1. I tested this patch-set alone on LX2162 Clearfog with SD1 Protocl 18 (i.e. 2x 10G SFP, 2x 25G SFP):
>
> 10Gbps ports are working fine!
>
> 25Gbps fail to probe (but this is partly expected):
>
> [ 8.373048] fsl_dpaa2_eth dpni.9 (unnamed net_device) (uninitialized): MAC returned PCS which does not support 25gbase-r
> [ 8.373065] fsl_dpaa2_eth dpni.9 (unnamed net_device) (uninitialized): MAC returned PCS which does not support 25gbase-r
> [ 8.373074] fsl_dpaa2_eth dpni.9 (unnamed net_device) (uninitialized): failed to validate link configuration for in-band status
> [ 8.373078] fsl_dpaa2_eth dpni.9 (unnamed net_device) (uninitialized): Error connecting to the MAC endpoint: -EINVAL
> [ 8.725004] fsl_dpaa2_eth dpni.9: probe with driver fsl_dpaa2_eth failed with error -22
> [ 8.920766] fsl_dpaa2_eth dpni.8 (unnamed net_device) (uninitialized): MAC returned PCS which does not support 25gbase-r
> [ 8.920783] fsl_dpaa2_eth dpni.8 (unnamed net_device) (uninitialized): MAC returned PCS which does not support 25gbase-r
> [ 8.920791] fsl_dpaa2_eth dpni.8 (unnamed net_device) (uninitialized): failed to validate link configuration for in-band status
> [ 8.920795] fsl_dpaa2_eth dpni.8 (unnamed net_device) (uninitialized): Error connecting to the MAC endpoint: -EINVAL
> [ 9.290005] fsl_dpaa2_eth dpni.8: probe with driver fsl_dpaa2_eth failed with error -22
>
> Perhaps driver could switch to 10G instead? However not important in my opinion.
>
> 2. Tested with additional out of tree patches:
>
> net: phylink: extend phylink_mii_c45_pcs_get_state also for PHY_INTERFACE_MODE_25GBASER
> net: pcs: lynx: extend support to also handle PHY_INTERFACE_MODE_25GBASER
>
> Then insert 10Gbps SFP module and link-up + TX/RX working fine!
> I.e. driver switched successfully from 25Gbps configuration to 10Gbps.
>
> Then insert 25Gbps SFP module. Errors start occuring:
>
> [ 357.043894] fsl_dpaa2_eth dpni.9 eth2: Link is Down
> [ 357.941036] sfp sfp-bt: module removed
> [ 364.269580] sfp sfp-bt: module FS SFP-25GSL-85 rev 1A sn C2501330127 dc 250203
> [ 364.269625] fsl_dpaa2_eth dpni.9 eth2: switched to inband/25gbase-r link mode
> [ 364.271674] fsl_dpaa2_eth dpni.9 eth2: phy_set_mode_ext() = -95
> [ 364.293232] hwmon hwmon8: temp1_input not attached to any thermal zone
>
> The link starts flapping, which is likely due to a combination of:
>
> 1. the lane has been halted but not stopped
> 2. the lane is still configured for 10G speed
> 3. the retimer (not supported by kernel) is still configured for 10G speed
>
> [ 364.333777] fsl_dpaa2_eth dpni.9 eth2: Link is Up - 25Gbps/Full - flow control off
> [ 365.280234] fsl_dpaa2_eth dpni.9 eth2: Link is Down
> [ 365.287750] fsl_dpaa2_eth dpni.9 eth2: Link is Up - 25Gbps/Full - flow control off
> [ 366.304434] fsl_dpaa2_eth dpni.9 eth2: Link is Down
> [ 366.311868] fsl_dpaa2_eth dpni.9 eth2: Link is Up - 25Gbps/Full - flow control off
> [ 367.328306] fsl_dpaa2_eth dpni.9 eth2: Link is Down
> ...
>
> So I reconfigure the retimer by i2cset for 25Gbps speed, and link goes down permanently.
>
> root@localhost:~# ethtool eth2
> Settings for eth2:
> Supported ports: [ FIBRE ]
> Supported link modes: 25000baseSR/Full
> Supported pause frame use: Symmetric Receive-only
> Supports auto-negotiation: No
> Supported FEC modes: Not reported
> Advertised link modes: Not reported
> Advertised pause frame use: No
> Advertised auto-negotiation: No
> Advertised FEC modes: Not reported
> Speed: Unknown!
> Duplex: Half
> Auto-negotiation: off
> Port: FIBRE
> PHYAD: 0
> Transceiver: internal
> Link detected: no
>
> I would give this a partial tested-by, considering it switched successfully to 10G,
> but failed switching to 25G, which is new with this patch. and needs extra patches.
I should clarify testing was done on v7.1-rc2, plus:
https://lore.kernel.org/r/0-v1-44b2fef88b25+d3-iommupt_map_rc_jgg@xxxxxxxxxx
https://lore.kernel.org/r/20260226182853.1103616-1-vladimir.oltean@xxxxxxx
https://lore.kernel.org/r/20260321011451.1557091-1-vladimir.oltean@xxxxxxx
https://lore.kernel.org/r/20260511150023.1903577-1-vladimir.oltean@xxxxxxx
I may have missed something important.