From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 257D8A0A02; Tue, 27 Apr 2021 17:09:28 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0D39541243; Tue, 27 Apr 2021 17:09:28 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mails.dpdk.org (Postfix) with ESMTP id 0CEC2410D8 for ; Tue, 27 Apr 2021 17:09:25 +0200 (CEST) IronPort-SDR: JKlR1xlIO53+DNwhX+3a8x7OSYYE4ioE0S563sWYJoUaDreKol3iy2+NZzdmdploEEOluByjoc WL+/xSmvVe8Q== X-IronPort-AV: E=McAfee;i="6200,9189,9967"; a="217237595" X-IronPort-AV: E=Sophos;i="5.82,254,1613462400"; d="scan'208";a="217237595" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Apr 2021 08:09:25 -0700 IronPort-SDR: NVPTCahOY0WJNCXCVwrR2TLDXw8e6ANGhb1WzsZ2ASvT5cttZwqjz4qTYoY7Zc6TTdnpjSKgv/ QfRV6gI18saA== X-IronPort-AV: E=Sophos;i="5.82,254,1613462400"; d="scan'208";a="457681077" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.221.231]) ([10.213.221.231]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Apr 2021 08:09:23 -0700 To: "Min Hu (Connor)" , dev@dpdk.org References: <1619056552-43937-4-git-send-email-humin29@huawei.com> <1619525859-4182-1-git-send-email-humin29@huawei.com> <3ffaf71d-3d39-579e-e9e0-56669f90f3c0@intel.com> From: Ferruh Yigit X-User: ferruhy Message-ID: <609abe57-ef0d-f96f-90f4-35494ad0728f@intel.com> Date: Tue, 27 Apr 2021 16:09:19 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v3] net/hns3: fix parse link fails code fail X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 4/27/2021 2:43 PM, Min Hu (Connor) wrote: > > > 在 2021/4/27 21:19, Ferruh Yigit 写道: >> On 4/27/2021 2:03 PM, Min Hu (Connor) wrote: >>> >>> >>> 在 2021/4/27 20:45, Ferruh Yigit 写道: >>>> On 4/27/2021 1:17 PM, Min Hu (Connor) wrote: >>>>> From: Chengwen Feng >>>>> >>>>> The link fails code should be parsed using the structure >>>>> hns3_mbx_vf_to_pf_cmd, else it will parse fail. >>>>> >>>>> Fixes: 109e4dd1bd7a ("net/hns3: get link state change through mailbox") >>>>> Cc: stable@dpdk.org >>>>> >>>>> Signed-off-by: Chengwen Feng >>>>> Signed-off-by: Min Hu (Connor) >>>>> --- >>>>> v3: >>>>> * get the parameter as 'struct hns3_mbx_vf_to_pf_cmd' at first place. >>>>> >>>>> v2: >>>>> * kept original API interface. >>>>> --- >>>>>    drivers/net/hns3/hns3_mbx.c | 11 +++++++++-- >>>>>    1 file changed, 9 insertions(+), 2 deletions(-) >>>>> >>>>> diff --git a/drivers/net/hns3/hns3_mbx.c b/drivers/net/hns3/hns3_mbx.c >>>>> index ba04ac9..31ab130 100644 >>>>> --- a/drivers/net/hns3/hns3_mbx.c >>>>> +++ b/drivers/net/hns3/hns3_mbx.c >>>>> @@ -347,7 +347,7 @@ hns3_link_fail_parse(struct hns3_hw *hw, uint8_t >>>>> link_fail_code) >>>>>      static void >>>>>    hns3pf_handle_link_change_event(struct hns3_hw *hw, >>>>> -                  struct hns3_mbx_pf_to_vf_cmd *req) >>>>> +                struct hns3_mbx_vf_to_pf_cmd *req) >>>>>    { >>>>>    #define LINK_STATUS_OFFSET     1 >>>>>    #define LINK_FAIL_CODE_OFFSET  2 >>>>> @@ -513,7 +513,14 @@ hns3_dev_handle_mbx_msg(struct hns3_hw *hw) >>>>>                hns3_handle_asserting_reset(hw, req); >>>>>                break; >>>>>            case HNS3_MBX_PUSH_LINK_STATUS: >>>>> -            hns3pf_handle_link_change_event(hw, req); >>>>> +            /* >>>>> +             * This message is reported by the firmware and is >>>>> +             * reported in 'struct hns3_mbx_vf_to_pf_cmd' format. >>>>> +             * Therefore, we should cast the req variable to >>>>> +             * 'struct hns3_mbx_vf_to_pf_cmd' and then process it. >>>>> +             */ >>>> >>>> I am asking just to double check, the 'msg' type is different of >>>> 'hns3_mbx_pf_to_vf_cmd' & 'hns3_mbx_vf_to_pf_cmd', one is 'uint8_t', other is >>>> 'uint16_t', and 'msg' is used in the function >>>> 'hns3pf_handle_link_change_event()'. >>>> Is the 'msg' usage still correct after this change? >>>> >>> Hi, it is correct. >>> Currently, msg from PF or VF are all handled in the same >>> handler（hns3_dev_handle_mbx_msg）, we do different handling >>> according to different msg. >>> In futrue, we will separate handler from PF and VF. >>> >> >> Let me clarify what I mean, 'msg' is accessed with an index like >> "req->msg[LINK_FAIL_CODE_OFFSET]", and the 'req->msg' type is different as you >> change the 'req' type. It changes 'uint8_t' -> 'uint16_t', which makes >> "req->msg[LINK_FAIL_CODE_OFFSET]" point completely different location, can you >> please confirm this is expected/correct? >> > Hi, it is corect, we have tested it. Applied to dpdk-next-net/main, thanks.