From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 943568E94 for ; Thu, 10 Sep 2015 06:39:04 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 09 Sep 2015 21:39:03 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,501,1437462000"; d="scan'208";a="801367681" Received: from shvmail01.sh.intel.com ([10.239.29.42]) by orsmga002.jf.intel.com with ESMTP; 09 Sep 2015 21:39:02 -0700 Received: from shecgisg004.sh.intel.com (shecgisg004.sh.intel.com [10.239.29.89]) by shvmail01.sh.intel.com with ESMTP id t8A4d0hY007370; Thu, 10 Sep 2015 12:39:00 +0800 Received: from shecgisg004.sh.intel.com (localhost [127.0.0.1]) by shecgisg004.sh.intel.com (8.13.6/8.13.6/SuSE Linux 0.8) with ESMTP id t8A4cvC5026566; Thu, 10 Sep 2015 12:38:59 +0800 Received: (from xiaowan1@localhost) by shecgisg004.sh.intel.com (8.13.6/8.13.6/Submit) id t8A4cv89026562; Thu, 10 Sep 2015 12:38:57 +0800 From: Wang Xiao W To: dev@dpdk.org Date: Thu, 10 Sep 2015 12:38:17 +0800 Message-Id: <1441859917-26475-9-git-send-email-xiao.w.wang@intel.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1441859917-26475-1-git-send-email-xiao.w.wang@intel.com> References: <1441859917-26475-1-git-send-email-xiao.w.wang@intel.com> Cc: Wang Xiao W Subject: [dpdk-dev] [PATCH 08/28] fm10k: ensure VF restores itr_scale on stop_hw X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 04:39:05 -0000 In a recent change, the ITR scale was given to the VF via TDLEN registers at driver initialization. This allows the VF to determine what the ITR scale for PCIe link speed should be. However, a VF unload followed by a reload incorrectly left this value as 0. Thus, the driver reloads and uses 0 as the ITR scale instead of the correct value. If the VF driver blindly trusted this value it could cause a divide by zero failure. Fix this by having stop_hw_vf reset the ITR scale as the device goes down, similar to the way we handle the MAC address. Signed-off-by: Wang Xiao W --- drivers/net/fm10k/base/fm10k_vf.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/net/fm10k/base/fm10k_vf.c b/drivers/net/fm10k/base/fm10k_vf.c index ce42189..7981417 100644 --- a/drivers/net/fm10k/base/fm10k_vf.c +++ b/drivers/net/fm10k/base/fm10k_vf.c @@ -41,7 +41,7 @@ POSSIBILITY OF SUCH DAMAGE. STATIC s32 fm10k_stop_hw_vf(struct fm10k_hw *hw) { u8 *perm_addr = hw->mac.perm_addr; - u32 bal = 0, bah = 0; + u32 bal = 0, bah = 0, tdlen; s32 err; u16 i; @@ -63,6 +63,9 @@ STATIC s32 fm10k_stop_hw_vf(struct fm10k_hw *hw) ((u32)perm_addr[2]); } + /* restore default itr_scale for next VF initialization */ + tdlen = hw->mac.itr_scale << FM10K_TDLEN_ITR_SCALE_SHIFT; + /* The queues have already been disabled so we just need to * update their base address registers */ @@ -71,6 +74,7 @@ STATIC s32 fm10k_stop_hw_vf(struct fm10k_hw *hw) FM10K_WRITE_REG(hw, FM10K_TDBAH(i), bah); FM10K_WRITE_REG(hw, FM10K_RDBAL(i), bal); FM10K_WRITE_REG(hw, FM10K_RDBAH(i), bah); + FM10K_WRITE_REG(hw, FM10K_TDLEN(i), tdlen); } return FM10K_SUCCESS; -- 1.9.3