From patchwork Tue Dec 29 02:32:05 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zhu Yanjun X-Patchwork-Id: 561421 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 0EEF6140BFC for ; Tue, 29 Dec 2015 13:32:18 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753007AbbL2CcM (ORCPT ); Mon, 28 Dec 2015 21:32:12 -0500 Received: from mail1.windriver.com ([147.11.146.13]:50017 "EHLO mail1.windriver.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751301AbbL2CcK (ORCPT ); Mon, 28 Dec 2015 21:32:10 -0500 Received: from ALA-HCA.corp.ad.wrs.com (ala-hca.corp.ad.wrs.com [147.11.189.40]) by mail1.windriver.com (8.15.2/8.15.1) with ESMTPS id tBT2W1PZ004543 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Dec 2015 18:32:01 -0800 (PST) Received: from sustaining-2.corp.ad.wrs.com (128.224.162.248) by ALA-HCA.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server id 14.3.248.2; Mon, 28 Dec 2015 18:32:00 -0800 From: To: , , , , , , , , , , CC: , , Subject: [PATCH 1/2] ixgbe: force to synchronize reporting "link on" and getting speed Date: Tue, 29 Dec 2015 10:32:05 +0800 Message-ID: <1451356326-2919-2-git-send-email-zyjzyj2000@gmail.com> X-Mailer: git-send-email 1.7.9.5 In-Reply-To: <1451356326-2919-1-git-send-email-zyjzyj2000@gmail.com> References: <1450926752-11392-1-git-send-email-zyjzyj2000@gmail.com> <1451356326-2919-1-git-send-email-zyjzyj2000@gmail.com> MIME-Version: 1.0 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: yzhu1 In X540 NIC, there is a time span between reporting "link on" and getting the speed and duplex. To a bonding driver in 802.3ad mode, this time span will make it not work well if the time span is big enough. The big time span will make bonding driver change the state of the slave device to up while the speed and duplex of the slave device can not be gotten. Later the bonding driver will not have change to get the speed and duplex of the slave device. The speed and duplex of the slave device are important to a bonding driver in 802.3ad mode. To 82599_SFP NIC and other kinds of NICs, this problem does not exist. As such, it is necessary for X540 to report"link on" when the link speed is not IXGBE_LINK_SPEED_UNKNOWN. Signed-off-by: yzhu1 Signed-off-by: Zhu Yanjun --- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c index aed8d02..ace21b9 100644 --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c @@ -6426,6 +6426,21 @@ static void ixgbe_watchdog_link_is_up(struct ixgbe_adapter *adapter) if (netif_carrier_ok(netdev)) return; + /* In X540 NIC, there is a time span between reporting "link on" + * and getting the speed and duplex. To a bonding driver in 802.3ad + * mode, this time span will make it not work well if the time span + * is big enough. To 82599_SFP NIC and other kinds of NICs, this + * problem does not exist. As such, it is better for X540 to report + * "link on" when the link speed is not IXGBE_LINK_SPEED_UNKNOWN. + * To other NICs, the link_up and link_speed are gotten at the same + * time. To X540 NIC, there is a time span between link_up and + * link_speed. As such, only continue if link_up and link_speed are + * ready to X540 NIC. + */ + if (hw->mac.type == ixgbe_mac_X540) + if (link_speed == IXGBE_LINK_SPEED_UNKNOWN) + return; + adapter->flags2 &= ~IXGBE_FLAG2_SEARCH_FOR_SFP; switch (hw->mac.type) {