Thread (16 messages) 16 messages, 5 authors, 2025-06-03

Re: [PATCH RFC net-next] net: phylink: always config mac for (delayed) phy

From: Eric Woudstra <hidden>
Date: 2025-01-07 14:23:21
Also in: bridge, linux-arm-kernel, linux-mediatek, lkml, netfilter-devel


On 1/7/25 2:20 PM, Andrew Lunn wrote:
quoted
I think it is because pl->act_link_an_mode stays at MLO_AN_INBAND, but
it needs to be set to MLO_AN_PHY, so that only the phy determines the
link state:

phylink_resolve() {
    ...
	} else if (pl->act_link_an_mode == MLO_AN_PHY) {
		link_state = pl->phy_state;
    ...
}
phylink tries to determine the whole chain is up. As Russell says, it
could be the PCS has not got sync with the PHY for some reason. So
even if you ignore the PCS state, it might not work. This is actually
a useful pieces of information. Does the link actually work end to end
if you only look at the media state? If it does, that would indicate
the PCS is maybe missing an interrupt, or needs polling for change in
state.

	Andrew
After phylink_mac_initial_config() is re-triggered with the phy
attached, either by the patch, or even with:

ethtool -s eth1 advertise 0x28
(switches to sgmii)
ethtool -s eth1 advertise 0x800000000028
(switches mac back to 2500base-x)

mode is set to MLO_AN_PHY in phylink_pcs_neg_mode() and the link works
end to end.

So the an-mode can be 2 different values, one after link up and another
after these ethtool commands.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help