Re: [PATCH phy-next 5/5] phy: lynx-28g: add support for 25GBASER

[Josua Mayer <josua@solid-run.com>]

Am 13.05.26 um 15:37 schrieb Vladimir Oltean:

> On Wed, May 13, 2026 at 11:37:14AM +0000, Josua Mayer wrote:
>> 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
> -95 is -EOPNOTSUPP. Is it coming from lynx_28g_set_mode()? If it is,
> I suppose it is from lynx_28g_supports_lane_mode() returning false.
>
> Assuming your list of additional patches is exhaustive, I think you
> missed from patch 4/5:
>
>  For old device trees with just "fsl,lynx-28g", the only things that
>  change are:
>  (...)
>
>  - the feature set is frozen in time (e.g. no 25GbE). Since we cannot
>    guarantee that this protocol will work on a lane, just err on the safe
>    side and don't offer it (and require a device tree update to get it).

Yes I missed that.

With updated compatible string it is working perfectly!

I'll send my tested-by on the series, thanks!

>
> You can look at my branch
> https://github.com/vladimiroltean/linux/commits/net-phy-upstreaming,
> specifically commit "arm64: dts: lx2160a: transition to device-specific
> SerDes compatible strings".

Thanks!

I will probably have retimer comments i.e. one phy object ehach for rx, and tx,
instead of combined - as we can not rely on hardware designers making clean choices.
E.g. imagine two retimer chips, one handling rx direction of 2 ports and one tx of 2 ports.

phys = <&serdes_1 0, &retimer_rx 0>, <&retimer_tx 0>;

Not relevant to this patch.
-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy