linux-kernel - [PATCH] PCI: Add device-specific reset for Kunpeng virtual functions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250712113028.15682-1-qianweili@huawei.com>
Date: Sat, 12 Jul 2025 19:30:28 +0800
From: Weili Qian <qianweili@...wei.com>
To: <bhelgaas@...gle.com>
CC: <linux-pci@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<liulongfang@...wei.com>, <qianweili@...wei.com>
Subject: [PATCH] PCI: Add device-specific reset for Kunpeng virtual functions

Prior to commit d591f6804e7e ("PCI: Wait for device readiness with
Configuration RRS"), pci_dev_wait() polls PCI_COMMAND register until
its value is not ~0(i.e., PCI_ERROR_RESPONSE). After d591f6804e7e,
if the Configuration Request Retry Status Software Visibility (RRS SV)
is enabled, pci_dev_wait() polls PCI_VENDOR_ID register until its value
is not the reserved Vendor ID value 0x0001.

On Kunpeng accelerator devices, RRS SV is enabled. However,
when the virtual function's FLR (Function Level Reset) is not
ready, the pci_dev_wait() reads the PCI_VENDOR_ID register and gets
the value 0xffff instead of 0x0001. It then incorrectly assumes this
is a valid Vendor ID and concludes the device is ready, returning
successfully. In reality, the function may not be fully ready, leading
to the device becoming unavailable.

A 100ms wait period is already implemented before calling pci_dev_wait().
In most cases, FLR completes within 100ms. However, to eliminate the
risk of function being unavailable due to an incomplete FLR, a
device-specific reset is added. After pcie_flr(), the function continues
to poll PCI_COMMAND register until its value is no longer ~0.

Fixes: d591f6804e7e ("PCI: Wait for device readiness with Configuration RRS")
Signed-off-by: Weili Qian <qianweili@...wei.com>
---
 drivers/pci/quirks.c | 36 ++++++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index d7f4ee634263..1df1756257d2 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4205,6 +4205,36 @@ static int reset_hinic_vf_dev(struct pci_dev *pdev, bool probe)
 	return 0;
 }

+#define KUNPENG_OPERATION_WAIT_CNT	3000
+#define KUNPENG_RESET_WAIT_TIME		20
+
+/* Device-specific reset method for Kunpeng accelerator virtual functions */
+static int reset_kunpeng_acc_vf_dev(struct pci_dev *pdev, bool probe)
+{
+	u32 wait_cnt = 0;
+	u32 cmd;
+
+	if (probe)
+		return 0;
+
+	pcie_flr(pdev);
+
+	do {
+		pci_read_config_dword(pdev, PCI_COMMAND, &cmd);
+		if (!PCI_POSSIBLE_ERROR(cmd))
+			break;
+
+		if (++wait_cnt > KUNPENG_OPERATION_WAIT_CNT) {
+			pci_warn(pdev, "wait for FLR ready timeout; giving up\n");
+			return -ENOTTY;
+		}
+
+		msleep(KUNPENG_RESET_WAIT_TIME);
+	} while (true);
+
+	return 0;
+}
+
 static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
 	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82599_SFP_VF,
 		 reset_intel_82599_sfp_virtfn },
@@ -4220,6 +4250,12 @@ static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
 		reset_chelsio_generic_dev },
 	{ PCI_VENDOR_ID_HUAWEI, PCI_DEVICE_ID_HINIC_VF,
 		reset_hinic_vf_dev },
+	{ PCI_VENDOR_ID_HUAWEI, PCI_DEVICE_ID_HUAWEI_ZIP_VF,
+		reset_kunpeng_acc_vf_dev },
+	{ PCI_VENDOR_ID_HUAWEI, PCI_DEVICE_ID_HUAWEI_SEC_VF,
+		reset_kunpeng_acc_vf_dev },
+	{ PCI_VENDOR_ID_HUAWEI, PCI_DEVICE_ID_HUAWEI_HPRE_VF,
+		reset_kunpeng_acc_vf_dev },
 	{ 0 }
 };

-- 
2.33.0