diff options
| author | Mike Pastore <mike@oobak.org> | 2023-05-07 10:35:19 +0300 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2024-04-27 18:07:10 +0300 |
| commit | f4aae2afe2d5497820d0ced9e4cf8af30088d32c (patch) | |
| tree | 6b44c99c4e2b46f02bec62360d7e79abcd362455 /drivers/pci | |
| parent | 0fe6a97a5fea6363442bb83500fb473daedadcf8 (diff) | |
| download | linux-f4aae2afe2d5497820d0ced9e4cf8af30088d32c.tar.xz | |
PCI: Delay after FLR of Solidigm P44 Pro NVMe
[ Upstream commit 0ac448e0d29d6ba978684b3fa2e3ac7294ec2475 ]
Prevent KVM hang when a Solidgm P44 Pro NVMe is passed through to a guest
via IOMMU and the guest is subsequently rebooted.
A similar issue was identified and patched by 51ba09452d11 ("PCI: Delay
after FLR of Intel DC P3700 NVMe") and the same fix can be applied for this
case. (Intel spun off their NAND and SSD business as Solidigm and sold it
to SK Hynix in late 2021.)
Link: https://lore.kernel.org/r/20230507073519.9737-1-mike@oobak.org
Signed-off-by: Mike Pastore <mike@oobak.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'drivers/pci')
| -rw-r--r-- | drivers/pci/quirks.c | 10 |
1 files changed, 6 insertions, 4 deletions
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index d8d3f817e95c..92169dc71468 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -4011,10 +4011,11 @@ static int nvme_disable_and_flr(struct pci_dev *dev, bool probe) } /* - * Intel DC P3700 NVMe controller will timeout waiting for ready status - * to change after NVMe enable if the driver starts interacting with the - * device too soon after FLR. A 250ms delay after FLR has heuristically - * proven to produce reliably working results for device assignment cases. + * Some NVMe controllers such as Intel DC P3700 and Solidigm P44 Pro will + * timeout waiting for ready status to change after NVMe enable if the driver + * starts interacting with the device too soon after FLR. A 250ms delay after + * FLR has heuristically proven to produce reliably working results for device + * assignment cases. */ static int delay_250ms_after_flr(struct pci_dev *dev, bool probe) { @@ -4101,6 +4102,7 @@ static const struct pci_dev_reset_methods pci_dev_reset_methods[] = { { PCI_VENDOR_ID_SAMSUNG, 0xa804, nvme_disable_and_flr }, { PCI_VENDOR_ID_INTEL, 0x0953, delay_250ms_after_flr }, { PCI_VENDOR_ID_INTEL, 0x0a54, delay_250ms_after_flr }, + { PCI_VENDOR_ID_SOLIDIGM, 0xf1ac, delay_250ms_after_flr }, { PCI_VENDOR_ID_CHELSIO, PCI_ANY_ID, reset_chelsio_generic_dev }, { PCI_VENDOR_ID_HUAWEI, PCI_DEVICE_ID_HINIC_VF, |