net/hns3: fix double stats for IMP and global reset

[ upstream commit c48e74370c5eafbe8db5c826a797344e4fdf8f49 ]

There is a stats counter for IMP and global reset in PF driver.
hns3 driver has two following task to detect reset event:
(1) interrupt handled task(A): triggered by interrupt and detect
    which reset level. And the reset service will be executed
    after 10us.
(2) polling task(B): scan reset source register to detect if
    driver has to do reset. And the reset service will be executed
    after deferred 3s.

They'll both count the number of one reset plus 1.
Task(A) adds it before doing the reset service. And in the reset service,
task(B) adds it if hw->reset.schedule is 'SCHEDULE_REQUESTED'.
Normally, this reset counter is just added by 1 once. Unfortunately,
this counter is added by 2 in the following case:
1. Task(B) detect the reset event, like IMP. hw->reset.schedule is
   set to 'SCHEDULE_REQUESTED'.
2. Task(A) is just triggered before running the reset service of task(B).
   Note: the reset counter is added by 1 at this moment before running
   the reset service of task(A). Additionally, the reset service of
   task(B) is canceled in task(A) because of schedule status being
   'SCHEDULE_REQUESTED'.
3. Then the reset service of task(A) is executed at last.
   Note: The reset counter is added by 1 again in this step because of
   schedule status still being 'SCHEDULE_REQUESTED'.

So this patch fix it by setting the scheduling status to
'SCHEDULE_REQUESTED' in step 2.

Fixes: 2790c64 ("net/hns3: support device reset")

Signed-off-by: Dengdui Huang <huangdengdui@huawei.com>

drivers/net/hns3/hns3_intr.c

@@ -1781,8 +1781,8 @@ hns3_schedule_reset(struct hns3_adapter *hns)
 		return;
 	if (rte_atomic16_read(&hns->hw.reset.schedule) == SCHEDULE_DEFERRED)
 		rte_eal_alarm_cancel(hw->reset.ops->reset_service, hns);
-	else
-		rte_atomic16_set(&hns->hw.reset.schedule, SCHEDULE_REQUESTED);
+
+	rte_atomic16_set(&hns->hw.reset.schedule, SCHEDULE_REQUESTED);
 
 	rte_eal_alarm_set(SWITCH_CONTEXT_US, hw->reset.ops->reset_service, hns);
 }