From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <netdev-owner@vger.kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by smtp.lore.kernel.org (Postfix) with ESMTP id B1757C77B6F
	for <netdev@archiver.kernel.org>; Mon, 10 Apr 2023 07:33:24 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S229774AbjDJHdX (ORCPT <rfc822;netdev@archiver.kernel.org>);
        Mon, 10 Apr 2023 03:33:23 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45100 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S229781AbjDJHdV (ORCPT
        <rfc822;netdev@vger.kernel.org>); Mon, 10 Apr 2023 03:33:21 -0400
Received: from smtpbg153.qq.com (smtpbg153.qq.com [13.245.218.24])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7A90C4698
        for <netdev@vger.kernel.org>; Mon, 10 Apr 2023 00:33:12 -0700 (PDT)
X-QQ-mid: Yeas5t1681111933t855t17530
Received: from 7082A6556EBF4E69829842272A565F7C (jiawenwu@trustnetic.com [183.129.236.74])
X-QQ-SSF: 00400000000000F0FL9000000000000
From:   =?utf-8?b?Smlhd2VuIFd1?= <jiawenwu@trustnetic.com>
X-BIZMAIL-ID: 10513836317384926707
To:     "'Russell King \(Oracle\)'" <linux@armlinux.org.uk>
Cc:     <netdev@vger.kernel.org>, <mengyuanlou@net-swift.com>
References: <20230403064528.343866-1-jiawenwu@trustnetic.com> <20230403064528.343866-6-jiawenwu@trustnetic.com> <ZCrY9Pqn+fID63s3@shell.armlinux.org.uk>
In-Reply-To: <ZCrY9Pqn+fID63s3@shell.armlinux.org.uk>
Subject: RE: [PATCH net-next 5/6] net: txgbe: Implement phylink pcs
Date:   Mon, 10 Apr 2023 15:32:12 +0800
Message-ID: <00a701d96b7e$90edb890$b2c929b0$@trustnetic.com>
MIME-Version: 1.0
Content-Type: text/plain;
        charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: zh-cn
Thread-Index: AQKwNRf195lW+I6aexcIjeJmW6Wh1gJHr+azAlWE08CtUaP1IA==
X-QQ-SENDSIZE: 520
Feedback-ID: Yeas:trustnetic.com:qybglogicsvr:qybglogicsvr5
Precedence: bulk
List-ID: <netdev.vger.kernel.org>
X-Mailing-List: netdev@vger.kernel.org

> > +				       struct phylink_link_state *state)
> > +{
> > +	int lpa, bmsr;
> > +
> > +	/* For C37 1000BASEX mode */
> > +	if (linkmode_test_bit(ETHTOOL_LINK_MODE_Autoneg_BIT,
> > +			      state->advertising)) {
> > +		/* Reset link state */
> > +		state->link = false;
> > +
> > +		/* Poll for link jitter */
> > +		read_poll_timeout(pcs_read, lpa, lpa,
> > +				  100, 50000, false, txgbe,
> > +				  MDIO_MMD_VEND2, MII_LPA);
> 
> What jitter are you referring to? If the link is down (and thus this
> register reads zero), why do we have to spin here for 50ms each time?
> 

I found that when the last interrupt arrives, the link status is often
still down, but it will become up after a while. It is about 30ms on my
test.
I can't find a good way to solve this problem at the moment, so just
delay some time.