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 79198A0A02; Tue, 27 Apr 2021 15:43:08 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 42289406A3; Tue, 27 Apr 2021 15:43:08 +0200 (CEST) Received: from szxga07-in.huawei.com (szxga07-in.huawei.com [45.249.212.35]) by mails.dpdk.org (Postfix) with ESMTP id F36514014E for ; Tue, 27 Apr 2021 15:43:06 +0200 (CEST) Received: from DGGEMS407-HUB.china.huawei.com (unknown [172.30.72.58]) by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4FV2vm4WGqzBsKg for ; Tue, 27 Apr 2021 21:40:36 +0800 (CST) Received: from [10.67.103.128] (10.67.103.128) by DGGEMS407-HUB.china.huawei.com (10.3.19.207) with Microsoft SMTP Server id 14.3.498.0; Tue, 27 Apr 2021 21:43:02 +0800 To: Ferruh Yigit , 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: "Min Hu (Connor)" Message-ID: Date: Tue, 27 Apr 2021 21:43:02 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: <3ffaf71d-3d39-579e-e9e0-56669f90f3c0@intel.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.103.128] X-CFilter-Loop: Reflected 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" 在 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. > >>>> +            hns3pf_handle_link_change_event(hw, >>>> +                (struct hns3_mbx_vf_to_pf_cmd *)req); >>> >>> Will it be more readable if 'desc->data' cast to "struct hns3_mbx_vf_to_pf_cmd >>> *" (instead of 'req')? Up to you, I can proceed with this one if you prefer. >>> . >> OK, thanks Ferruh. > > So do you prefer to continue as it is, or will there be a change? > continue as it is, thanks. > . >