Unverified Commit 264cea76 authored Apr 09, 2025 by openeuler-ci-bot Committed by Gitee Apr 09, 2025

!15650 PCI/DPC: Ignore Surprise Down error on hot removal

Merge Pull Request from: @lujunhuaHW 
 
 PCI/DPC: Ignore Surprise Down error on hot removal

Issue：https://gitee.com/openeuler/kernel/issues/IBWFCP


Contents described in the synchronization protocol:
According to PCIe r6.0 sec 6.7.6 [1], async removal with DPC may result in
surprise down error. This error is expected and is just a side-effect of
async remove.

Ignore surprise down error generated as a side-effect of async remove.
Typically, this error is benign as the pciehp handler invoked by PDC
or/and DLLSC alongside DPC, de-enumerates and brings down the device
appropriately, but the error messages might confuse users. Get rid of
these irritating log messages with a 1s delay while pciehp waits for
DPC recovery.

The implementation is as follows: On an async remove a DPC is triggered
along with a Presence Detect State change and/or DLL State Change.
Determine it's an async remove by checking for DPC Trigger Status in DPC
Status Register and Surprise Down Error Status in AER Uncorrected Error
Status to be non-zero. If true, treat the DPC event as a side-effect of
async remove, clear the error status registers and continue with hot-plug
tear down routines. If not, follow the existing routine to handle AER and
DPC errors.

Masking Surprise Down Errors was explored as an alternative approach, but
discarded due to the odd behavior that masking only avoids the interrupt,
but still records an error per PCIe r6.0, sec 6.2.3.2.2. That stale error
would be reported the next time some error other than Surprise Down is
handled. 
 
Link:https://gitee.com/openeuler/kernel/pulls/15650

 

Reviewed-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: Zhang Peng <zhangpeng362@huawei.com>

parents 5dc0a311 c56fd295

drivers/pci/pcie/dpc.c

+60 −0

Original line number	Diff line number	Diff line
		@@ -293,10 +293,70 @@ void dpc_process_error(struct pci_dev *pdev)
		}
		}

		static void pci_clear_surpdn_errors(struct pci_dev *pdev)
		{
		if (pdev->dpc_rp_extensions)
		pci_write_config_dword(pdev, pdev->dpc_cap +
		PCI_EXP_DPC_RP_PIO_STATUS, ~0);

		/*
		* In practice, Surprise Down errors have been observed to also set
		* error bits in the Status Register as well as the Fatal Error
		* Detected bit in the Device Status Register.
		*/
		pci_write_config_word(pdev, PCI_STATUS, 0xffff);

		pcie_capability_write_word(pdev, PCI_EXP_DEVSTA, PCI_EXP_DEVSTA_FED);
		}

		static void dpc_handle_surprise_removal(struct pci_dev *pdev)
		{
		if (!pcie_wait_for_link(pdev, false)) {
		pci_info(pdev, "Data Link Layer Link Active not cleared in 1000 msec\n");
		goto out;
		}

		if (pdev->dpc_rp_extensions && dpc_wait_rp_inactive(pdev))
		goto out;

		pci_aer_raw_clear_status(pdev);
		pci_clear_surpdn_errors(pdev);

		pci_write_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_STATUS,
		PCI_EXP_DPC_STATUS_TRIGGER);

		out:
		clear_bit(PCI_DPC_RECOVERED, &pdev->priv_flags);
		wake_up_all(&dpc_completed_waitqueue);
		}

		static bool dpc_is_surprise_removal(struct pci_dev *pdev)
		{
		u16 status;

		if (!pdev->is_hotplug_bridge)
		return false;

		if (pci_read_config_word(pdev, pdev->aer_cap + PCI_ERR_UNCOR_STATUS,
		&status))
		return false;

		return status & PCI_ERR_UNC_SURPDN;
		}

		static irqreturn_t dpc_handler(int irq, void *context)
		{
		struct pci_dev *pdev = context;

		/*
		* According to PCIe r6.0 sec 6.7.6, errors are an expected side effect
		* of async removal and should be ignored by software.
		*/
		if (dpc_is_surprise_removal(pdev)) {
		dpc_handle_surprise_removal(pdev);
		return IRQ_HANDLED;
		}

		dpc_process_error(pdev);

		/* We configure DPC so it only triggers on ERR_FATAL */