[PATCH v5 phy-next 13/16] phy: lynx-28g: improve phy_validate() procedure

Ioana Ciornei ioana.ciornei at nxp.com
Thu Jun 11 04:50:51 PDT 2026


On Wed, Jun 10, 2026 at 06:19:49PM +0300, Vladimir Oltean wrote:
> lynx_28g_validate() suffers from the following shortcomings:
> 
> - Changing the protocol should not be possible if the source protocol of
>   the lane is unsupported. This is because lynx_28g_proto_conf[] only
>   covers the register deltas between any pair of supported lane modes,
>   but that delta is probably incomplete if the source protocol is, say,
>   PCIe (which is currently assimilated by the driver to
>   LANE_MODE_UNKNOWN).
> 
>   lynx_28g_proto_conf() does refuse changing the protocol if the current
>   one is unsupported, but we shouldn't advertise it via phy_validate()
>   at all.
> 
>   The phy_set_mode_ext() call should perform the exact same
>   verifications as phy_validate() did, in case the caller bypassed
>   phy_validate(). So we need to centralize the logic into a common
>   validation. But lynx_28g_set_mode() later needs the lane_mode that
>   this validation needs to compute anyway, so name the common helper
>   lynx_phy_mode_to_lane_mode() and let it return that lane_mode.
> 
> - Future core sanity checks on phy_validate() will want to differentiate
>   the case where this optional method is not implemented from the case
>   where the mode/submode is really not supported. So we shouldn't return
>   -EOPNOTSUPP from lynx_28g_validate(), but -EINVAL to signal that we do
>   implement the operation:
>   https://lore.kernel.org/linux-phy/aY2lFTIALH7qEJmM@shell.armlinux.org.uk/
> 
> Signed-off-by: Vladimir Oltean <vladimir.oltean at nxp.com>

Reviewed-by: Ioana Ciornei <ioana.ciornei at nxp.com>



More information about the linux-phy mailing list