Message-ID: <fbcbfdc4-5f20-4dbc-9e46-e9c28fc399c8@linux.intel.com>
Date: Sat, 22 Feb 2025 08:26:02 +0800
From: "Abdul Rahim, Faizal" <faizal.abdul.rahim@...ux.intel.com>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: Furong Xu <0x1207@...il.com>, Tony Nguyen <anthony.l.nguyen@...el.com>,
 Przemek Kitszel <przemyslaw.kitszel@...el.com>,
 Andrew Lunn <andrew+netdev@...n.ch>, "David S . Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 Maxime Coquelin <mcoquelin.stm32@...il.com>,
 Alexandre Torgue <alexandre.torgue@...s.st.com>,
 Simon Horman <horms@...nel.org>, Russell King <linux@...linux.org.uk>,
 Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>,
 Jesper Dangaard Brouer <hawk@...nel.org>,
 John Fastabend <john.fastabend@...il.com>,
 Russell King <rmk+kernel@...linux.org.uk>,
 Serge Semin <fancer.lancer@...il.com>,
 Xiaolei Wang <xiaolei.wang@...driver.com>,
 Suraj Jaiswal <quic_jsuraj@...cinc.com>,
 Kory Maincent <kory.maincent@...tlin.com>, Gal Pressman <gal@...dia.com>,
 Jesper Nilsson <jesper.nilsson@...s.com>,
 Andrew Halaney <ahalaney@...hat.com>,
 Choong Yong Liang <yong.liang.choong@...ux.intel.com>,
 Kunihiko Hayashi <hayashi.kunihiko@...ionext.com>,
 Vinicius Costa Gomes <vinicius.gomes@...el.com>,
 intel-wired-lan@...ts.osuosl.org, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-stm32@...md-mailman.stormreply.com,
 linux-arm-kernel@...ts.infradead.org, bpf@...r.kernel.org
Subject: Re: [PATCH iwl-next v5 1/9] net: ethtool: mm: extract stmmac
 verification logic into common library



On 21/2/2025 10:44 pm, Vladimir Oltean wrote:
> On Fri, Feb 21, 2025 at 09:30:09PM +0800, Abdul Rahim, Faizal wrote:
>> On 21/2/2025 6:43 pm, Vladimir Oltean wrote:
>>> On Fri, Feb 21, 2025 at 06:24:09PM +0800, Furong Xu wrote:
>>>> Your fix is better when link is up/down, so I vote verify_enabled.
>>>
>>> Hmmm... I thought this was a bug in stmmac that was carried over to
>>> ethtool_mmsv, but it looks like it isn't.
>>>
>>> In fact, looking at the original refactoring patch I had attached in
>>> this email:
>>> https://lore.kernel.org/netdev/20241217002254.lyakuia32jbnva46@skbuf/
>>>
>>> these 2 lines in ethtool_mmsv_link_state_handle() didn't exist at all.
>>>
>>> 	} else {
>>>>>>> 		mmsv->status = ETHTOOL_MM_VERIFY_STATUS_INITIAL;
>>>>>>> 		mmsv->verify_retries = ETHTOOL_MM_MAX_VERIFY_RETRIES;
>>>
>>> 		/* No link or pMAC not enabled */
>>> 		ethtool_mmsv_configure_pmac(mmsv, false);
>>> 		ethtool_mmsv_configure_tx(mmsv, false);
>>> 	}
>>>
>>> Faizal, could you remind me why they were added? I don't see this
>>> explained in change logs.
>>>
>>
>> Hi Vladimir,
>>
>> Yeah, it wasn’t there originally. I added that change because it failed the
>> link down/link up test.
>> After a successful verification, if the link partner goes down, the status
>> still shows ETHTOOL_MM_VERIFY_STATUS_SUCCEEDED, which isn’t correct—so
>> that’s why I added it.
>>
>> Sorry for not mentioning it earlier. I assumed you’d check the delta between
>> the original patch and the upstream one, my bad, should have mentioned this
>> logic change.
>>
>> Should I update it to the latest suggestion?
> 
> Never, ever modify logic in the same commit as you are moving code.
> I was wondering what's with the Co-developed-by: tags, but I had just
> assumed fixups were made to code I had improperly moved because I
> didn't have hardware to test. Always structure patches to be one single
> logical change per patch, well justified and trivially correct.

Got it, sorry about that.

> I had assumed, in good faith, changes like this wouldn't sneak in, but I
> guess thanks for letting me know I should check next time :)
> 
> I think it's a slightly open question which state should the verification
> be in when the link fails, but in any case, your argument could be made
> that the state of the previous verification should be lost.
> 
> If I look at figure 99-8 in the Verify state diagram, I see that
> whenever the condition "begin || link_fail || disableVerify || !pEnable"
> is true, we transition to the state INIT_VERIFICATION. From there, there
> is a UCT (unconditional transition) to VERIFICATION_IDLE, and from there,
> a transition to state SEND_VERIFY based on "pEnable && !disableVerify".
> In principle what this is telling me is that as long as management
> software doesn't set pEnable (tx_enable in Linux) to false, verification
> would be attempted even with link down, and should eventually fail.
> 
> But the mmsv state machine does call ethtool_mmsv_configure_tx(mmsv, false),
> and in that case, if I were to interpret the standard state machine very
> strictly, it would remain blocked in state VERIFICATION_IDLE until a
> link up (thus, we should report the state as "verifying").
> 
> But, to be honest, I think the existence of the VERIFICATION_IDLE state
> doesn't make a lot of sense. The state machine should just transition on
> "!link_fail && !disable_verify && pEnable" to SEND_VERIFY directly, and
> from state WAIT_FOR_RESPONSE it should cycle back to SEND_VERIFY if the
> verify timer expired but we still have retries, or to INIT_VERIFICATION
> if link_fail, disableVerify or pEnable change. One more reason why I
> believe the VERIFICATION_IDLE state is redundant and under-specified is
> because it gives the user no chance to even _see_ the "initial" state
> being reported ever, given the unconditional transition to VERIFICATION_IDLE.
> 
> So in that sense, I agree with your proposal, and in terms of code,
> I would recommend just this:
> 
>   } else {
> +	/* Reset the reported verification state while the link is down */
> +	if (mmsv->verify_enabled)
> +		mmsv->status = ETHTOOL_MM_VERIFY_STATUS_INITIAL;
>   
>   	/* No link or pMAC not enabled */
>   	ethtool_mmsv_configure_pmac(mmsv, false);
>   	ethtool_mmsv_configure_tx(mmsv, false);
>   }
> 
> Because this is just for reporting to user space, resetting
> "mmsv->verify_retries = ETHTOOL_MM_MAX_VERIFY_RETRIES;" doesn't matter,
> we'll do it on link up anyway.
> 
> Also note that there's no ternary operator like in the discussion with
> Furong. If mmsv->verify_enabled is false, the mmsv->status should
> already be DISABLED, no need for us to re-assign it.
> 

Will update, thanks.

Powered by blists - more mailing lists