[PATCH net v1 1/1] net: phylink: keep initial advertising settings

[PATCH net v1 1/1] net: phylink: keep initial advertising settings

[Thilo Zirnstein]

If the net device is phylink based,
consists of a mac with a phy connected and the
mac driver does add the phy while the ndo_open callback,
initial advertising settings of the link may be overwritten
during phylink_bringup_phy.

The mode of action is as follows:

* The link was not up yet - no phy connected
* the user configures the advertisement of the interface
* the mac driver delegates the call to phylink_ethtool_ksettings_set
    * here we are not configuring the phy - it does not exist yet
* the user set up the interface
* the mac drivers calls phylink_connect_phy
    * calls phylink_bringup_phy
        * overwrites advertisement with
            * linkmode_copy(config.advertising, phy->advertising);
            * linkmode_copy(pl->link_config.advertising,
                config.advertising);

Connecting the phy while ndo_open callback seems to be a common pattern,
affected drivers are:

* macb
* r8169
* stmmac
* tn40xx

The advertising settings can be kept by using the intersection
of the phylink advert bits and the phy advert bits.

This was observed and tested on a
Xilinx Zyqnmp system with builtin macb ethernet interface.

Fixes: 9525ae83959b ("phylink: add phylink infrastructure")
Signed-off-by: Thilo Zirnstein <thi.zirnstein@gmail.com>
---
 drivers/net/phy/phylink.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index e885da1c2831..145f181bc9d3 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -2320,6 +2320,7 @@ static int phylink_bringup_phy(struct phylink *pl, struct phy_device *phy,
 	pl->phy_state.duplex = DUPLEX_UNKNOWN;
 	pl->phy_state.rate_matching = RATE_MATCH_NONE;
 	linkmode_copy(pl->supported, supported);
+	linkmode_and(config.advertising, config.advertising, pl->link_config.advertising);
 	linkmode_copy(pl->link_config.advertising, config.advertising);

 	/* Restrict the phy advertisement according to the MAC support. */
--
2.43.0

Re: [PATCH net v1 1/1] net: phylink: keep initial advertising settings

[Andrew Lunn]

On Wed, Nov 04, 2026 at 01:55:09PM +0100, Thilo Zirnstein wrote:
> If the net device is phylink based,
> consists of a mac with a phy connected and the
> mac driver does add the phy while the ndo_open callback,
> initial advertising settings of the link may be overwritten
> during phylink_bringup_phy.
> 
> The mode of action is as follows:
> 
> * The link was not up yet - no phy connected
> * the user configures the advertisement of the interface
> * the mac driver delegates the call to phylink_ethtool_ksettings_set
>     * here we are not configuring the phy - it does not exist yet

If it does not exist, it is not possible to validate the user request
is actually supported by the PHY.

> * the user set up the interface
> * the mac drivers calls phylink_connect_phy

At this point, is the previously configured value sanitised by what
the PHY can actually do?

Take the example of a MAC which can do up to 2500BaseX, but it is
connected to a PHY which only supports SGMII. Before up, the user
could request 2.5GBaseT, but at admin up that needs to be reduced down
to 1G.

	Andrew

Re: [PATCH net v1 1/1] net: phylink: keep initial advertising settings

[Thilo Zirnstein]

Hi Andrew,

Thanks for your feedback,

On Fri, Nov 06, 2026 at 02:51:18PM +0100, Andrew Lunn wrote:
...
> > The mode of action is as follows:
> > 
> > * The link was not up yet - no phy connected
> > * the user configures the advertisement of the interface
> > * the mac driver delegates the call to phylink_ethtool_ksettings_set
> >     * here we are not configuring the phy - it does not exist yet
> 
> If it does not exist, it is not possible to validate the user request
> is actually supported by the PHY.

I think my description was a bit misleading.
The mode of action describes how the phy is attached by some
net driver and what the program flow is and why there is a problem.

Typically the device driver does not set/clear any advertisment bits
during device bring up. As least what I have seen so far.
It attaches the phy and brings up the link.

> 
> > * the user set up the interface
> > * the mac drivers calls phylink_connect_phy
> 
> At this point, is the previously configured value sanitised by what
> the PHY can actually do?
> 
> Take the example of a MAC which can do up to 2500BaseX, but it is
> connected to a PHY which only supports SGMII. Before up, the user
> could request 2.5GBaseT, but at admin up that needs to be reduced down
> to 1G.

Good example, with this patch applied this will advertise 1G,
if the user does not configure exclusive 2.5G prior attaching the phy.
If the user configures exclusive 2.5G (2.5G only) the advertisment is empty.
I think this is fine because the user missconfigured the link, but maybe
i am to restrictive.

I wrote a little table for a better overview. I am not 100% sure
how your example behaves because 2.5G uses another interface then SGMII.
I have tested with a sgmii 1G half/full duplex link.

Without patch

without phy (user):     phy caps        link up advertisement
1G FD+HD                1G FD+HD        1G FD+HD
1G FD                   1G FD+HD        1G FD+HD <= bad
1G FD+HD                1G FD           1G FD

With patch

without phy (user):     phy caps    link up advertisement
1G FD+HD                1G FD+HD    1G FD+HD   
1G FD                   1G FD+HD    1G FD <= good
1G FD+HD                1G FD       1G FD

> 	Andrew

Thilo