[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