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 D8F1842B3A for ; Thu, 18 May 2023 13:32:05 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8CA8742D3E; Thu, 18 May 2023 13:32:05 +0200 (CEST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by mails.dpdk.org (Postfix) with ESMTP id 53E0442B71; Thu, 18 May 2023 13:32:01 +0200 (CEST) Received: from kwepemi500017.china.huawei.com (unknown [172.30.72.54]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4QMST92mgdzLmNV; Thu, 18 May 2023 19:30:37 +0800 (CST) Received: from localhost.localdomain (10.28.79.22) by kwepemi500017.china.huawei.com (7.221.188.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Thu, 18 May 2023 19:31:58 +0800 From: Dongdong Liu To: , , , , CC: , , , Subject: [PATCH 4/5] net/hns3: fix receive multiple firmware reset interrupts Date: Thu, 18 May 2023 19:29:43 +0800 Message-ID: <20230518112944.32276-5-liudongdong3@huawei.com> X-Mailer: git-send-email 2.22.0 In-Reply-To: <20230518112944.32276-1-liudongdong3@huawei.com> References: <20230518112944.32276-1-liudongdong3@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.28.79.22] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To kwepemi500017.china.huawei.com (7.221.188.110) X-CFilter-Loop: Reflected X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 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 From: Chengwen Feng In the firmware (also known as IMP) reset scenario, driver interrupt processing and firmware watchdog initialization are asynchronous. If the driver interrupt processing is faster than firmware watchdog initialization (that is, the driver clears the firmware reset interrupt source before the firmware watchdog is initialized), the driver will receive multiple firmware reset interrupts. In the Kunpeng 920 platform, the above situation does not exist. But it does on the newer platforms. So we add 5ms delay before drivers clears the IMP reset interrupt source. As for the impact of 5ms, the number of PFs managed by a firmware is limited. Therefore, even if a DPDK process takes over all the PFs which managed by the firmware, the delay is controllable. Cc: stable@dpdk.org Signed-off-by: Chengwen Feng Signed-off-by: Dongdong Liu --- drivers/net/hns3/hns3_ethdev.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c index 5ef66f96c6..664226a6ef 100644 --- a/drivers/net/hns3/hns3_ethdev.c +++ b/drivers/net/hns3/hns3_ethdev.c @@ -286,6 +286,19 @@ hns3_handle_mac_tnl(struct hns3_hw *hw) } } +static void +hns3_delay_before_clear_event_cause(struct hns3_hw *hw, uint32_t event_type, uint32_t regclr) +{ +#define IMPRESET_WAIT_MS_TIME 5 + + if (event_type == HNS3_VECTOR0_EVENT_RST && + regclr & BIT(HNS3_VECTOR0_IMPRESET_INT_B) && + hw->revision >= PCI_REVISION_ID_HIP09_A) { + rte_delay_ms(IMPRESET_WAIT_MS_TIME); + hns3_dbg(hw, "wait firmware watchdog initialization completed."); + } +} + static void hns3_interrupt_handler(void *param) { @@ -305,6 +318,7 @@ hns3_interrupt_handler(void *param) vector0_int = hns3_read_dev(hw, HNS3_VECTOR0_OTHER_INT_STS_REG); ras_int = hns3_read_dev(hw, HNS3_RAS_PF_OTHER_INT_STS_REG); cmdq_int = hns3_read_dev(hw, HNS3_VECTOR0_CMDQ_SRC_REG); + hns3_delay_before_clear_event_cause(hw, event_cause, clearval); hns3_clear_event_cause(hw, event_cause, clearval); /* vector 0 interrupt is shared with reset and mailbox source events. */ if (event_cause == HNS3_VECTOR0_EVENT_ERR) { -- 2.22.0