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

[Eric Woudstra <ericwouds@gmail.com>]

On 1/7/25 4:03 PM, Russell King (Oracle) wrote:
> On Tue, Jan 07, 2025 at 02:14:03PM +0100, Eric Woudstra wrote:
>>
>>
>> On 1/7/25 1:47 PM, Russell King (Oracle) wrote:
>>> Going through the log...
>>>
>>> On Tue, Jan 07, 2025 at 01:36:15PM +0100, Eric Woudstra wrote:
>>>> Log before this patch is applied:
>>>> [root@bpir3 ~]# dmesg | grep eth1
>>>> [    2.515179] mtk_soc_eth 15100000.ethernet eth1: mediatek frame engine at 0xffff800082380000, irq 123
>>>> [   38.271431] mtk_soc_eth 15100000.ethernet eth1: configuring for inband/2500base-x link mode
>>>> [   38.279828] mtk_soc_eth 15100000.ethernet eth1: major config, requested inband/2500base-x
>>>> [   38.288009] mtk_soc_eth 15100000.ethernet eth1: interface 2500base-x inband modes: pcs=01 phy=00
>>>> [   38.296800] mtk_soc_eth 15100000.ethernet eth1: major config, active inband/inband,an-disabled/2500base-x
>>>
>>> This is indeed without the PHY. We're using inband, although the PCS
>>> mode is PHYLINK_PCS_NEG_INBAND_DISABLED, meaning inband won't be
>>> used. As there is no PHY, we can't switch to MLO_AN_PHY.
>>>
>>>> [   38.306362] mtk_soc_eth 15100000.ethernet eth1: phylink_mac_config: mode=inband/2500base-x/none adv=00,00000000,00008000,0000e240 pause=04
>>>> [   39.220149] mtk_soc_eth 15100000.ethernet eth1:  interface 2 (mii) rate match none supports 0-3,6-7,13-14
>>>> [   39.229758] mtk_soc_eth 15100000.ethernet eth1:  interface 3 (gmii) rate match none supports 0-3,5-7,13-14
>>>> [   39.239420] mtk_soc_eth 15100000.ethernet eth1:  interface 4 (sgmii) rate match none supports 0-3,5-7,13-14
>>>> [   39.249173] mtk_soc_eth 15100000.ethernet eth1:  interface 22 (1000base-x) rate match none supports 5-7,13-14
>>>> [   39.259080] mtk_soc_eth 15100000.ethernet eth1:  interface 23 (2500base-x) rate match none supports 6-7,13-14,47
>>>> [   39.594676] mtk_soc_eth 15100000.ethernet eth1: PHY i2c:sfp-1:11 uses interfaces 4,23, validating 4,23
>>>
>>> The PHY comes along...
>>>
>>>> [   39.603992] mtk_soc_eth 15100000.ethernet eth1:  interface 4 (sgmii) rate match none supports 0-3,5-7,13-14
>>>> [   39.650080] mtk_soc_eth 15100000.ethernet eth1:  interface 23 (2500base-x) rate match none supports 6-7,13-14,47
>>>> [   39.660266] mtk_soc_eth 15100000.ethernet eth1: PHY [i2c:sfp-1:11] driver [RTL8221B-VB-CG 2.5Gbps PHY (C45)] (irq=POLL)
>>>> [   39.671037] mtk_soc_eth 15100000.ethernet eth1: phy: 2500base-x setting supported 00,00000000,00008000,000060ef advertising 00,00000000,00008000,000060ef
>>>> [   39.684761] mtk_soc_eth 15100000.ethernet eth1: requesting link mode inband/2500base-x with support 00,00000000,00008000,000060ef
>>>
>>> We decide to use MLO_AN_INBAND and 2500base-X, which we're already using.
>>>
>>>> [   40.380076] mtk_soc_eth 15100000.ethernet eth1: phy link down 2500base-x/Unknown/Unknown/none/off
>>>> [   40.397090] brlan: port 5(eth1) entered blocking state
>>>> [   40.402223] brlan: port 5(eth1) entered disabled state
>>>> [   40.407437] mtk_soc_eth 15100000.ethernet eth1: entered allmulticast mode
>>>> [   40.414400] mtk_soc_eth 15100000.ethernet eth1: entered promiscuous mode
>>>> [   44.500077] mtk_soc_eth 15100000.ethernet eth1: phy link up 2500base-x/2.5Gbps/Full/none/off
>>>> [   44.508528] mtk_soc_eth 15100000.ethernet eth1: No phy led trigger registered for speed(2500)
>>>
>>> ... but we don't see link-up reported by the PCS after the PHY comes
>>> up. Why is that - I think that needs investigation before we proceed
>>> to patch the issue, because that suggests the PCS isn't seeing
>>> valid 2500base-X from the PHY.
>>>
>>
>> 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;
>>     ...
>> }
> 
> Please see my reply to Daniel. The PCS should still be capable of
> reporting whether its link is up or down irrespective of whether
> in-band status is being used or not.
> 
> While it is correct that PHY mode needs to be used here, your report
> has pointed out that the driver is not reporting the PCS link state
> correctly when in-band is disabled.
> 
> Given that the current state of affairs has revealed this other bug,
> I would like that addressed first while there is a trivial test case
> here.
> 

So I've narrowed down the problem a bit:

At first state->link is set to true, while looking at the bmsr.

But because linkmode_test_bit(fd_bit, state->advertising) and
linkmode_test_bit(fd_bit, state->lp_advertising) are both false,
state->link is set to false after looking at the bmsr.

void phylink_mii_c22_pcs_decode_state(struct phylink_link_state *state,
				      u16 bmsr, u16 lpa)
{
	state->link = !!(bmsr & BMSR_LSTATUS);
	...
	case PHY_INTERFACE_MODE_2500BASEX:
		phylink_decode_c37_word(state, lpa, SPEED_2500);
	...
}

static void phylink_decode_c37_word(struct phylink_link_state *state,
				    uint16_t config_reg, int speed)
{
	...
	if (linkmode_test_bit(fd_bit, state->advertising) &&
	    linkmode_test_bit(fd_bit, state->lp_advertising)) {
		state->speed = speed;
		state->duplex = DUPLEX_FULL;
	} else {
		/* negotiation failure */
		state->link = false;
	}
	...
}

And I can confirm, if I change the part above into the part below
(removing the if statement), the PCS also reports the link is up and the
connection is functional end-to-end. Not that I'm saying this change is
the solution, only for narrowing down the problem.

static void phylink_decode_c37_word(struct phylink_link_state *state,
				    uint16_t config_reg, int speed)
{
	...
	state->speed = speed;
	state->duplex = DUPLEX_FULL;
	...
}

Also worth mentioning, up until v12 of the pcs-mtk-lynxy.c
mtk_pcs_lynxi_get_state() did not call
phylink_mii_c22_pcs_decode_state() at all for 2500base-x.