On Fri, Apr 19, 2019 at 11:05:45AM +0800, Huazhong Tan wrote:
From: Weihang Li <liweihang@xxxxxxxxxxxxx>Is this running in interrupt context ever? I don't think it is, but the
MAC tnl interruptions are different from other type of RAS and MSI-X
errors, because some bits, such as OVF/LR/RF will occur during link up
and down.
The drivers should clear status of all MAC tnl interruption bits but
shouldn't print any message that would mislead the users.
In case that link down and re-up in a short time because of some reasons,
we record when they occurred, and users can query them by debugfs.
Signed-off-by: Weihang Li <liweihang@xxxxxxxxxxxxx>
Signed-off-by: Peng Li <lipeng321@xxxxxxxxxx>
---
<snip>>
bool en)
{
@@ -1611,6 +1636,7 @@ pci_ers_result_t hclge_handle_hw_ras_error(struct hnae3_ae_dev *ae_dev)
int hclge_handle_hw_msix_error(struct hclge_dev *hdev,
unsigned long *reset_requests)
{
+ struct hclge_mac_tnl_stats mac_tnl_stats;
struct device *dev = &hdev->pdev->dev;
u32 mpf_bd_num, pf_bd_num, bd_num;
enum hnae3_reset_type reset_level;
@@ -1745,6 +1771,31 @@ int hclge_handle_hw_msix_error(struct hclge_dev *hdev,
set_bit(HNAE3_GLOBAL_RESET, reset_requests);
}
+ /* query and clear mac tnl interruptions */
+ hclge_cmd_setup_basic_desc(&desc[0], HCLGE_OPC_QUERY_MAC_TNL_INT,
+ true);
+ ret = hclge_cmd_send(&hdev->hw, &desc[0], 1);
function name makes me think otherwise. If it is, this could be unsafe as you
take a spinlock in hclge_cmd_send, which is protected against bottom halves, but
not interrupts. That could cause a deadlock if there is a path to get here
directly from an interrupt context.
Neil
.