Re: What is the purpose of the first phylink_validate() call from phylink_create()?

[Vladimir Oltean <vladimir.oltean@nxp.com>]

On Thu, Oct 05, 2023 at 10:16:48AM +0100, Russell King (Oracle) wrote:
> You've found the exact reason for it - so that we report something that
> seems at least reasonable to userspace, rather than reporting absolutely
> nothing which may cause issues.

Thanks for confirming. I don't need to change the user-observable behavior,
I think I can work my way around it. I just wanted to know what to look for,
and I deleted the phylink_validate() call just to exaggerate the effect.

> The original code in mvneta would've done this:
> 
> int mvneta_ethtool_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
> {
>         struct mvneta_port *pp = netdev_priv(dev);
> 
>         if (!pp->phy_dev)
>                 return -ENODEV;
> 
>         return phy_ethtool_gset(pp->phy_dev, cmd);
> }
> 
> Thus making the call fail if the device wasn't up - and that may be
> an alternative if we're expecting a PHY but we have none.

Ok, but I admit I don't know how to make phylink_ethtool_ksettings_get()
return -ENODEV just for this case. For example, I'm thinking of the
situation of a copper SFP module with an inaccessible PHY, using SGMII.
My understanding is that phylink_expects_phy() would return true, so
that helper couldn't be used to discern this kind of SFP from a PHY
which is accessible but phylink_bringup_phy() wasn't yet called on it.

In any case, please consider the question answered for now with no other
actionable item.

Also, I now see that patchwork thinks this question is a patch
(https://patchwork.kernel.org/project/netdevbpf/patch/20231004222523.p5t2cqaot6irstwq@skbuf/),
so:

pw-bot: not-applicable