From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 51B3BA051C for ; Tue, 11 Feb 2020 12:28:54 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 49C4B2B9C; Tue, 11 Feb 2020 12:28:54 +0100 (CET) Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by dpdk.org (Postfix) with ESMTP id 2F3ED2B9C for ; Tue, 11 Feb 2020 12:28:53 +0100 (CET) Received: by mail-wr1-f68.google.com with SMTP id z3so11911245wru.3 for ; Tue, 11 Feb 2020 03:28:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=1Y++nOCqpxpVRsfCgLSb4P3+IWncg8WHLJHHAsF2/4M=; b=jhVUVkpt6D+KzPdccIbA4kOkwc9Za7tPsFJYsaXLcO497savG07brD8gU0+S8LoM0i AauRkf6rZKVvsgVCvXukfX2X6zp04Uge+/jfDGIZf6NdmCCzcRn62UA76/ZHVP1T8hZw 6KObLTSpS0bNQjo0gSnUYxYyZvC/jaOe0tXHEwt45S0mdgUPh5FEkz5ZU+sTo59TmwHF w2rFh0sPW27PTF/GbBpDm70CozmENIOI9kiM3e5gBvb+OhPzadOxAsnbCsW3eoRN2wLX ZE2xSVwqNjKbgNmnMYJ0INaD6w2TMZy3bhocaa6qpI+kAp8OCTxa0WZUrTlHD+1sdyeR jPXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=1Y++nOCqpxpVRsfCgLSb4P3+IWncg8WHLJHHAsF2/4M=; b=tZR+zBR68B5RzjT9+6Lz4cQLz8et7W8YK4uQHhUBkdhbjnYQmp5Ryn7HHite9nCazL 9140AcYdgX1q+/jMxvdS5cATM2dqOhxlZztjjmnYQlJrHpOynufxVai/9ZN6OwPtiFKp vlF/0c8dWgZGWFLMDsB5DyTjSWv+1AvXkXN8/rpfDXjwp9xAQhXDAHH2I5Yvncslvkmm dHbnf+pgVkZJuPxMlDTqldfYQhFEUyjjsiOM3Johz97jNYDqbkj+HfPKDjGZFq2UmTVE LRBYGgnY1za36+or4jnTtfCdRnEN5DhtqAjYo/KrFSOujNJk/ALAUI9Qc00tUYXW72YE MmOw== X-Gm-Message-State: APjAAAWFfz6aQnoAdTVXOqrqeGXjV0VWss+OLwC4i16CnlaEoV0as1tT a3Zlv27Y+9IxpTdqOqOC2zw= X-Google-Smtp-Source: APXvYqwF5cH+r0tlVrc8oTDeiG8/ZzcQWZYLSyrNzhy/oCr/v7ON17kNTTWC9nBWtEryN+5KnJv8Gw== X-Received: by 2002:a5d:640d:: with SMTP id z13mr7794091wru.181.1581420532898; Tue, 11 Feb 2020 03:28:52 -0800 (PST) Received: from localhost ([88.98.246.218]) by smtp.gmail.com with ESMTPSA id c4sm3286020wml.7.2020.02.11.03.28.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Feb 2020 03:28:52 -0800 (PST) From: luca.boccassi@gmail.com To: "Wei Hu (Xavier)" Cc: Chengwen Feng , dpdk stable Date: Tue, 11 Feb 2020 11:20:27 +0000 Message-Id: <20200211112216.3929-81-luca.boccassi@gmail.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200211112216.3929-1-luca.boccassi@gmail.com> References: <20200211112216.3929-1-luca.boccassi@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [dpdk-stable] patch 'net/hns3: fix dumping VF register information' has been queued to stable release 19.11.1 X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" Hi, FYI, your patch has been queued to stable release 19.11.1 Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet. It will be pushed if I get no objections before 02/13/20. So please shout if anyone has objections. Also note that after the patch there's a diff of the upstream commit vs the patch applied to the branch. This will indicate if there was any rebasing needed to apply to the stable branch. If there were code changes for rebasing (ie: not only metadata diffs), please double check that the rebase was correctly done. Thanks. Luca Boccassi --- >From bc69de759e5734e4ba6beedcb769b484f84dfe56 Mon Sep 17 00:00:00 2001 From: "Wei Hu (Xavier)" Date: Thu, 9 Jan 2020 11:15:57 +0800 Subject: [PATCH] net/hns3: fix dumping VF register information [ upstream commit fc066e6accfd593362b2786a7153557727b36e11 ] Currently, when the API interface named rte_eth_dev_get_reg_info is called by upper applications based on VF device, it returns error. We can read registers directly to get ring and interrupt related information in hns3 PF/VF PMD driver. But for some other internal table entries and common configuration information, we can get them only through the command interface between driver and firmware in PF driver, and VF driver has not the related access permission. This patch fixes it by preventing getting these information through the command interface based on VF device in 'get_reg' ops implementation function. Fixes: 936eda25e8da ("net/hns3: support dump register") Signed-off-by: Chengwen Feng Signed-off-by: Wei Hu (Xavier) --- drivers/net/hns3/hns3_regs.c | 29 ++++++++++++++++++----------- 1 file changed, 18 insertions(+), 11 deletions(-) diff --git a/drivers/net/hns3/hns3_regs.c b/drivers/net/hns3/hns3_regs.c index 23405030e7..a3f2a51f9b 100644 --- a/drivers/net/hns3/hns3_regs.c +++ b/drivers/net/hns3/hns3_regs.c @@ -118,15 +118,9 @@ hns3_get_regs_length(struct hns3_hw *hw, uint32_t *length) struct hns3_adapter *hns = HNS3_DEV_HW_TO_ADAPTER(hw); int cmdq_lines, common_lines, ring_lines, tqp_intr_lines; uint32_t regs_num_32_bit, regs_num_64_bit; + uint32_t len; int ret; - ret = hns3_get_regs_num(hw, ®s_num_32_bit, ®s_num_64_bit); - if (ret) { - hns3_err(hw, "Get register number failed, ret = %d.", - ret); - return -ENOTSUP; - } - cmdq_lines = sizeof(cmdq_reg_addrs) / REG_LEN_PER_LINE + 1; if (hns->is_vf) common_lines = @@ -136,11 +130,21 @@ hns3_get_regs_length(struct hns3_hw *hw, uint32_t *length) ring_lines = sizeof(ring_reg_addrs) / REG_LEN_PER_LINE + 1; tqp_intr_lines = sizeof(tqp_intr_reg_addrs) / REG_LEN_PER_LINE + 1; - *length = (cmdq_lines + common_lines + ring_lines * hw->tqps_num + - tqp_intr_lines * hw->num_msi) * REG_LEN_PER_LINE + - regs_num_32_bit * sizeof(uint32_t) + - regs_num_64_bit * sizeof(uint64_t); + len = (cmdq_lines + common_lines + ring_lines * hw->tqps_num + + tqp_intr_lines * hw->num_msi) * REG_LEN_PER_LINE; + if (!hns->is_vf) { + ret = hns3_get_regs_num(hw, ®s_num_32_bit, ®s_num_64_bit); + if (ret) { + hns3_err(hw, "Get register number failed, ret = %d.", + ret); + return -ENOTSUP; + } + len += regs_num_32_bit * sizeof(uint32_t) + + regs_num_64_bit * sizeof(uint64_t); + } + + *length = len; return 0; } @@ -346,6 +350,9 @@ hns3_get_regs(struct rte_eth_dev *eth_dev, struct rte_dev_reg_info *regs) /* fetching per-PF registers values from PF PCIe register space */ hns3_direct_access_regs(hw, data); + if (hns->is_vf) + return 0; + ret = hns3_get_regs_num(hw, ®s_num_32_bit, ®s_num_64_bit); if (ret) { hns3_err(hw, "Get register number failed, ret = %d", ret); -- 2.20.1 --- Diff of the applied patch vs upstream commit (please double-check if non-empty: --- --- - 2020-02-11 11:17:41.782420434 +0000 +++ 0081-net-hns3-fix-dumping-VF-register-information.patch 2020-02-11 11:17:38.516003516 +0000 @@ -1,8 +1,10 @@ -From fc066e6accfd593362b2786a7153557727b36e11 Mon Sep 17 00:00:00 2001 +From bc69de759e5734e4ba6beedcb769b484f84dfe56 Mon Sep 17 00:00:00 2001 From: "Wei Hu (Xavier)" Date: Thu, 9 Jan 2020 11:15:57 +0800 Subject: [PATCH] net/hns3: fix dumping VF register information +[ upstream commit fc066e6accfd593362b2786a7153557727b36e11 ] + Currently, when the API interface named rte_eth_dev_get_reg_info is called by upper applications based on VF device, it returns error. @@ -17,7 +19,6 @@ function. Fixes: 936eda25e8da ("net/hns3: support dump register") -Cc: stable@dpdk.org Signed-off-by: Chengwen Feng Signed-off-by: Wei Hu (Xavier)