Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp1491908pxb; Thu, 28 Oct 2021 04:55:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzuBLFtZr4DnASrJg8n5XYkbpgsD1k+0JXGTCjx4sxZvBKJYQpUGHfWeKZIZXTZUMBUDtnI X-Received: by 2002:a05:6a00:24c5:b0:47c:2094:e16a with SMTP id d5-20020a056a0024c500b0047c2094e16amr3861489pfv.54.1635422143442; Thu, 28 Oct 2021 04:55:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635422143; cv=none; d=google.com; s=arc-20160816; b=c182YGKdc5ZZA9H8iazclD0JpVgt8naljBME+V15jU34NGrzoN4TTGIhiC9O5apnDi mcHjyIj0e2xspvBuYqQfNM+cbw8UC6jg3QCBhDOmBhK9rK4g87GppAICmqpK2PU4ErUn +cb31/2F2ZRacC9G2iYt1daHivQQN3k7AHhMMiAy1updyChD6YUa1pO1mSOMjlJ0rsDi hYepHALi/rd2iaSSp3SUJULnD29tQWg5yKw+lMeblnDjDRBNkyzcRHVEvUhXQi9QK0p9 kiO1Q5gy1d+b2/x/sir52mS3gxAdwDAgGoPT1Ac1BRh6igls1X5Y1Zrw09GENJQ2S7Hx Vvyg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=gItn1y1TzzIBoBlCDks1RVM7G4z4QGVFszoo+jOKGDc=; b=ZiN/8V6fHs45fYRXvPXPjUXLeGGW3PbhdUmA69b4lxqcfv/AgfDCE/tYFfkbvmmm0X VuTRz/U4manvYxyY1nXG/5PbdizGOJw9DeqUBwK0AqnJv4CHs+qhbs6PxpTy/JnaG7Mn ngewjc10UH1kC8k+XY+7nqTwWFmOq4je0rRAk4+GtfbH92BWKcXS6XoIcKTHHzZDgXQO ZoLz4yNvKGwzoX6jAhr7QUMUFZe5MO8iqVWsCaCiBqFfhm5hheXYt9xV63+zDOTVqOSJ Ypyy1qJdbxQg6O+1qKVj2ILYMJve6s4zYz+PmfAdPrQ6stLW/5Hl+LSE7c3Wx1Im2tys RjUA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 66si3086975pfe.242.2021.10.28.04.55.30; Thu, 28 Oct 2021 04:55:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230135AbhJ1L4j (ORCPT + 99 others); Thu, 28 Oct 2021 07:56:39 -0400 Received: from szxga02-in.huawei.com ([45.249.212.188]:14872 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229835AbhJ1L4i (ORCPT ); Thu, 28 Oct 2021 07:56:38 -0400 Received: from dggemv703-chm.china.huawei.com (unknown [172.30.72.54]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4Hg3qs05qFz90VG; Thu, 28 Oct 2021 19:54:01 +0800 (CST) Received: from kwepemm600016.china.huawei.com (7.193.23.20) by dggemv703-chm.china.huawei.com (10.3.19.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Thu, 28 Oct 2021 19:54:04 +0800 Received: from [10.67.102.67] (10.67.102.67) by kwepemm600016.china.huawei.com (7.193.23.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Thu, 28 Oct 2021 19:54:03 +0800 Subject: Re: [PATCH net 1/7] net: hns3: fix pause config problem after autoneg disabled To: Andrew Lunn CC: , , , , , , References: <20211027121149.45897-1-huangguangbin2@huawei.com> <20211027121149.45897-2-huangguangbin2@huawei.com> From: "huangguangbin (A)" Message-ID: <09eda9fe-196b-006b-6f01-f54e75715961@huawei.com> Date: Thu, 28 Oct 2021 19:54:02 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.102.67] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To kwepemm600016.china.huawei.com (7.193.23.20) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021/10/28 1:23, Andrew Lunn wrote: > On Wed, Oct 27, 2021 at 08:11:43PM +0800, Guangbin Huang wrote: > > The semantics are not too well defined here, the ethtool documentation > is not too clear. Here is how i interpret it. > >> If a TP port is configured by follow steps: >> 1.ethtool -s ethx autoneg off speed 100 duplex full > > So you turn general autoneg off > >> 2.ethtool -A ethx rx on tx on > > You did not use autoneg off here. Pause autoneg is separate to general > autoneg. So pause autoneg is still enabled at this point. That means > you should not directly configure the MAC with the pause > configuration, you only do that when pause autoneg is off. You can > consider this as setting how you want pause to be negotiated once > general autoneg is re-enabled. > >> 3.ethtool -s ethx autoneg on(rx&tx negotiated pause results are off) > > So you reenable general autoneg. As part of that general autoneg, > pause will re-renegotiated, and it should you the preferences you set > in 2, that rx and tx pause can be used. What is actually used depends > on the link peer. The link_adjust callback from phylib tells you how > to program the MAC. > >> 4.ethtool -s ethx autoneg off speed 100 duplex full > > So you turn general autoneg off again. It is unclear how you are > supposed to program the MAC, but i guess most systems keep with the > result from the last autoneg. > > Looking at your patch, there are suspicious calls to phy_syspend and > phy_resume. They don't look correct at all, and i'm not aware of any > other MAC driver doing this. Now, i know the behaviour is not well > defined here, but i'm not sure your interpretation is valid and how > others interpret it. > > Andrew > . > Hi Andrew, thanks very much for your guidance on how to use pause autoneg, it confuses me before because PHY registers actually have no separate setting bit of pause autoneg. So, summarize what you mean: 1. If pause autoneg is on, driver should always use the autoneg result to program the MAC. Eventhough general autoneg is off now and link state is no changed then driver just needs to keep the last configuration for the MAC, if link state is changed and phy goes down and up then driver needs to program the MAC according to the autoneg result in the link_adjust callback. 2. If pause autoneg is off, driver should directly configure the MAC with tx pause and rx pause. Eventhough general autoneg is on, driver should ignore the autoneg result. Do I understand right? Guangbin .