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

[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(-)
> +static int lynx_28g_e25g_pcvt(int lane)
> +{
> +	return 7 - lane;
> +}
> +
>  static int lynx_28g_get_pccr(enum lynx_lane_mode lane_mode, int lane,
>  			     struct lynx_pccr *pccr)
>  {
> @@ -776,6 +840,11 @@ static int lynx_28g_get_pccr(enum lynx_lane_mode lane_mode, int lane,
>  		pccr->width = 4;
>  		pccr->shift = SXGMII_CFG(lane);
>  		break;
> +	case LANE_MODE_25GBASER:
> +		pccr->offset = PCCD;
> +		pccr->width = 4;
> +		pccr->shift = E25G_CFG(lynx_28g_e25g_pcvt(lane));
> +		break;
>  	default:
>  		return -EOPNOTSUPP;
>  	}
Wouldn't it be more clear instead of indirect lane offset shift with
lynx_28g_e25g_pcvt, to instead fix the E25G_CFG definition?:

-#define E25G_CFG(id) (28 - (id) * 4) /* Offset into PCCD */
+#define E25G_CFG(id) ((id) * 4)      /* Offset into PCCD */

This is equivalent when inserting (7 - lane) into E25G_CFG id:

(28 - (id) * 4) = (28 - (7 - lane) * 4) = (28 - 7*4 + lane*4)