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

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

[Vladimir Oltean]

Hi Russell,

In phylink_create() we have this code which populates pl->supported with
a maximal link mode configuration and then makes a best-effort attempt
to reduce it to what the physical port actually supports:

diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index 3951e5af8cb5..1e89634ec8ae 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -1677,10 +1677,6 @@ struct phylink *phylink_create(struct phylink_config *config,
 	__set_bit(PHYLINK_DISABLE_STOPPED, &pl->phylink_disable_state);
 	timer_setup(&pl->link_poll, phylink_fixed_poll, 0);
 
-	bitmap_fill(pl->supported, __ETHTOOL_LINK_MODE_MASK_NBITS);
-	linkmode_copy(pl->link_config.advertising, pl->supported);
-	phylink_validate(pl, pl->supported, &pl->link_config);
-
 	ret = phylink_parse_mode(pl, fwnode);
 	if (ret < 0) {
 		kfree(pl);

However:

- in MLO_AN_FIXED mode, the later call to phylink_parse_fixedlink() will
  overwrite this pl->supported and pl->link_config.advertising with
  another set

- in MLO_AN_INBAND mode, the later call to phylink_parse_mode() will
  also overwrite pl->supported and pl->link_config.advertising

- with a PHY (either in MLO_AN_INBAND or MLO_AN_PHY modes),
  phylink_bringup_phy() will overwrite pl->supported and
  pl->link_config.advertising with stuff from the PHY

Of these 3 cases, phylink_bringup_phy() is the only one which
potentially does not come immediately after phylink_create().
So, the effect of the phylink_validate() from phylink_create() will be
visible only when it's not overwritten, for example when phylink_connect_phy()
(or one of variants) isn't called at probe time but is delayed until
ndo_open().

Since mvneta calls phylink_of_phy_connect() from mvneta_open() and I can
test that, I'm comparing the "ethtool" output produced before running
"ip link set dev eth0 up", in 2 cases:

- With the phylink_validate() from phylink_create() kept in place:

$ ethtool eth0
Settings for eth0:
        Supported ports: [ TP    AUI     MII     FIBRE   BNC     Backplane ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
                                1000baseKX/Full
                                1000baseX/Full
                                100baseT1/Full
                                1000baseT1/Full
                                100baseFX/Half 100baseFX/Full
                                10baseT1L/Full
                                10baseT1S/Full
                                10baseT1S/Half
                                10baseT1S_P2MP/Half
        Supported pause frame use: Symmetric
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  Not reported
        Advertised pause frame use: No
        Advertised auto-negotiation: No
        Advertised FEC modes: Not reported
        Speed: Unknown!
        Duplex: Half
        Auto-negotiation: off
        Port: MII
        PHYAD: 0
        Transceiver: internal
        Supports Wake-on: d
        Wake-on: d
        Link detected: no

- And with it removed (the diff from the beginning):

$ ethtool eth0
Settings for eth0:
        Supported ports: [  ]
        Supported link modes:   Not reported
        Supported pause frame use: No
        Supports auto-negotiation: No
        Supported FEC modes: Not reported
        Advertised link modes:  Not reported
        Advertised pause frame use: No
        Advertised auto-negotiation: No
        Advertised FEC modes: Not reported
        Speed: Unknown!
        Duplex: Half
        Auto-negotiation: off
        Port: MII
        PHYAD: 0
        Transceiver: internal
        Supports Wake-on: d
        Wake-on: d
        Link detected: no

But I'm not sure that this ethtool output is very valuable to user space?
At this stage it is essentially just the output of phylink_generic_validate()
for the MAC_10 | MAC_100 | MAC_1000FD | MAC_2500FD capabilities using a
gigabit phy_interface_t. It is subject to change as more link modes get
introduced. The output with no link modes reported until the PHY connects
seems at least equally reasonable, given that the PHY dictates the link modes.

So what is the purpose of the early phylink_validate() call and the
associated population of pl->supported? Is it just to report some link
modes until we have a PHY and we're not in-band, or am I missing something?

On a visual inspection, this code structure exists since commit
9525ae83959b ("phylink: add phylink infrastructure"), but I cannot test
as far back as that to be absolutely sure.

For reference, here is the ethtool output when the port has been brought up:

$ ethtool eth0
Settings for eth0:
        Supported ports: [ TP    MII     FIBRE ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supported pause frame use: Symmetric
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
                                             1000baseT/Full
        Link partner advertised pause frame use: Symmetric Receive-only
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Full
        Auto-negotiation: on
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: external
        MDI-X: Unknown
        Supports Wake-on: pg
        Wake-on: d
        Link detected: yes

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

[Russell King (Oracle)]

On Thu, Oct 05, 2023 at 01:25:23AM +0300, Vladimir Oltean wrote:
> Hi Russell,
> 
> In phylink_create() we have this code which populates pl->supported with
> a maximal link mode configuration and then makes a best-effort attempt
> to reduce it to what the physical port actually supports:
> 
> diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
> index 3951e5af8cb5..1e89634ec8ae 100644
> --- a/drivers/net/phy/phylink.c
> +++ b/drivers/net/phy/phylink.c
> @@ -1677,10 +1677,6 @@ struct phylink *phylink_create(struct phylink_config *config,
>  	__set_bit(PHYLINK_DISABLE_STOPPED, &pl->phylink_disable_state);
>  	timer_setup(&pl->link_poll, phylink_fixed_poll, 0);
>  
> -	bitmap_fill(pl->supported, __ETHTOOL_LINK_MODE_MASK_NBITS);
> -	linkmode_copy(pl->link_config.advertising, pl->supported);
> -	phylink_validate(pl, pl->supported, &pl->link_config);
> -
>  	ret = phylink_parse_mode(pl, fwnode);
>  	if (ret < 0) {
>  		kfree(pl);
> 
> However:
> 
> - in MLO_AN_FIXED mode, the later call to phylink_parse_fixedlink() will
>   overwrite this pl->supported and pl->link_config.advertising with
>   another set
> 
> - in MLO_AN_INBAND mode, the later call to phylink_parse_mode() will
>   also overwrite pl->supported and pl->link_config.advertising
> 
> - with a PHY (either in MLO_AN_INBAND or MLO_AN_PHY modes),
>   phylink_bringup_phy() will overwrite pl->supported and
>   pl->link_config.advertising with stuff from the PHY
> 
> Of these 3 cases, phylink_bringup_phy() is the only one which
> potentially does not come immediately after phylink_create().
> So, the effect of the phylink_validate() from phylink_create() will be
> visible only when it's not overwritten, for example when phylink_connect_phy()
> (or one of variants) isn't called at probe time but is delayed until
> ndo_open().
> 
> Since mvneta calls phylink_of_phy_connect() from mvneta_open() and I can
> test that, I'm comparing the "ethtool" output produced before running
> "ip link set dev eth0 up", in 2 cases:
> 
> - With the phylink_validate() from phylink_create() kept in place:
> 
> $ ethtool eth0
> Settings for eth0:
>         Supported ports: [ TP    AUI     MII     FIBRE   BNC     Backplane ]
>         Supported link modes:   10baseT/Half 10baseT/Full
>                                 100baseT/Half 100baseT/Full
>                                 1000baseT/Full
>                                 1000baseKX/Full
>                                 1000baseX/Full
>                                 100baseT1/Full
>                                 1000baseT1/Full
>                                 100baseFX/Half 100baseFX/Full
>                                 10baseT1L/Full
>                                 10baseT1S/Full
>                                 10baseT1S/Half
>                                 10baseT1S_P2MP/Half
>         Supported pause frame use: Symmetric
>         Supports auto-negotiation: Yes
>         Supported FEC modes: Not reported
>         Advertised link modes:  Not reported
>         Advertised pause frame use: No
>         Advertised auto-negotiation: No
>         Advertised FEC modes: Not reported
>         Speed: Unknown!
>         Duplex: Half
>         Auto-negotiation: off
>         Port: MII
>         PHYAD: 0
>         Transceiver: internal
>         Supports Wake-on: d
>         Wake-on: d
>         Link detected: no
> 
> - And with it removed (the diff from the beginning):
> 
> $ ethtool eth0
> Settings for eth0:
>         Supported ports: [  ]
>         Supported link modes:   Not reported
>         Supported pause frame use: No
>         Supports auto-negotiation: No
>         Supported FEC modes: Not reported
>         Advertised link modes:  Not reported
>         Advertised pause frame use: No
>         Advertised auto-negotiation: No
>         Advertised FEC modes: Not reported
>         Speed: Unknown!
>         Duplex: Half
>         Auto-negotiation: off
>         Port: MII
>         PHYAD: 0
>         Transceiver: internal
>         Supports Wake-on: d
>         Wake-on: d
>         Link detected: no

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.

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.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

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

[Vladimir Oltean]

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