The TM QCN error event should report by RAS other than MSIX.
Also this patch adds fifo int enable configuration before the TM QCN
error event is enabled.
Fixes: f53a793bb7 ("net/hns3: add more hardware error types")
Fixes: 3903c05382 ("net/hns3: remove read when enabling TM QCN error event")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Kunpeng 930 uses a new RAS exception reporting solution.
The reset type and exception status are reported through
firmware. The driver modifies the corresponding code to
adapt to the new solution.
Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Currently, VF driver periodically obtains link status from PF kernel
driver, and reports lsc event when detects link status change. Because
the period is 1 second, it's probably too late to report especially
in such as bonding scenario.
To solve this problem we use the following scheme:
1. PF kernel driver support immediate push link status to all VFs when
it detects the link status changes.
2. VF driver will detect PF kernel driver whether support push link
status in device init stage by sending request link info mailbox
message to PF, PF then tell VF the push capability by extend
HNS3_MBX_LINK_STAT_CHANGE mailbox message.
3. VF driver marks RTE_PCI_DRV_INTR_LSC in rte_pci_driver by default,
when it detects PF doesn't support push link status then it will clear
RTE_ETH_DEV_INTR_LSC flag.
So if PF kernel driver supports push link status to VF, then VF driver
will have RTE_ETH_DEV_INTR_LSC capability.
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
This patch updates copyright date for hns3 PMD files.
Fixes: 565829db8b ("net/hns3: add build and doc infrastructure")
Fixes: 952ebacce4 ("net/hns3: support SVE Rx")
Fixes: e31f123db0 ("net/hns3: support NEON Tx")
Fixes: c09c7847d8 ("net/hns3: support traffic management")
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
According to the suggestion of our legal department,
to standardize the copyright license of our code to
avoid potential copyright risks, we make a unified
modification to the "Hisilicon", which was nonstandard,
in the main modules we maintain.
We change it to "HiSilicon", which is consistent with
the terms used on the following official website:
https://www.hisilicon.com/en/terms-of-use.
Fixes: 565829db8b ("net/hns3: add build and doc infrastructure")
Fixes: 952ebacce4 ("net/hns3: support SVE Rx")
Fixes: e31f123db0 ("net/hns3: support NEON Tx")
Fixes: c09c7847d8 ("net/hns3: support traffic management")
Cc: stable@dpdk.org
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
TNL is the abbreviation of tunnel, which means port
here. MAC TNL interrupt indicates the MAC status
report of the network port, which will be generated
when the MAC status changes.
This patch enables MAC TNL interrupt reporting, and
queries and prints the corresponding MAC status when
the interrupt is received, then clear the MAC interrupt
status. Because this interrupt uses the same interrupt
as RAS, the interrupt log is adjusted.
Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Some header files have included by others. Also,
some header files have a header file self-contained
error will trigger building warning. As a result,
it is unnecessary and move it into the correct
location.
Beside, here also remove some unused lines.
Signed-off-by: Lijun Ou <oulijun@huawei.com>
The new firmware adds the hardware error types reported by MSI-x mode.
These errors are defined as RAS errors in hardware and belong to a
different type from the MSI-x errors processed by the driver.
When hardware detects an error which must be handled by the driver for
device to run properly it reports the error information through the
MSI-x interrupt. After receiving the interrupt reported by the hardware,
the driver queries the error information and identifies the error level,
then rectifies the error. All errors will be logged.
In addition, the hardware may be reset at the function or global level
based on the error level. After the reset is complete, the hardware will
recover to the normal status.
Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
This patch adds reset related process for hns3 PMD driver.
The following three scenarios will trigger the reset process,
and the driver settings will be restored after the reset is
successful:
1. Receive a reset interrupt
2. PF receives a hardware error interrupt
3. VF is notified by PF to reset
Signed-off-by: Chunsong Feng <fengchunsong@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Signed-off-by: Hao Chen <chenhao164@huawei.com>
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
This patch adds abnormal interrupt process for hns3 PMD driver,
the interrupt reported by NIC hardware.
Signed-off-by: Chunsong Feng <fengchunsong@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
Signed-off-by: Hao Chen <chenhao164@huawei.com>
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
