> Which leads me to believe that the longer delay before the first config
> space access required by this particular card is a quirk. So I'm
> proposing the following patch:
>
>
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 20ac67d..3cbff71 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -5993,3 +5993,9 @@ static void dpc_log_size(struct pci_dev *dev)
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x9a2f, dpc_log_size);
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x9a31,
> dpc_log_size);
> #endif
> +
> +static void pci_fixup_d3cold_delay_1sec(struct pci_dev *pdev)
> +{
> + pdev->d3cold_delay = 1000;
> +}
> +DECLARE_PCI_FIXUP_FINAL(0x5555, 0x0004, pci_fixup_d3cold_delay_1sec);
>
>
> Could you test if applying this on top of v6.1.16 fixes the issue?
> (Apply with "patch -p1 < filename.patch" at the top of the kernel
> source tree.)
>
> Thanks,
>
> Lukas
I've applied the quirk patch to v6.5.4 and it does indeed elicit the same successful result as the original ssleep delay.
The device and server are functioning as expected.
