On Mon, 2020-02-24 at 08:15 -0600, Bjorn Helgaas wrote: > [+cc Ashok, Alex, Sinan, Rajat] > > On Sun, Feb 23, 2020 at 01:20:55PM +0100, Stanislav Spassov wrote: > > From: Wei Wang <wawei@xxxxxxxxx> > > > > The resonable value for the maximum time to wait for a PCI device to be > > ready after reset varies depending on the platform and the reliability > > of its set of devices. > > There are several mechanisms in the spec for reducing these times, > e.g., Readiness Notifications (PCIe r5.0, sec 6.23), the Readiness > Time Reporting capability (sec 7.9.17), and ACPI _DSM methods (PCI > Firmware Spec r3.2, sec 4.6.8, 4.6.9). > > I would much rather use standard mechanisms like those instead of > adding kernel parameters. A user would have to use trial and error > to figure out the value to use with a parameter like this, and that > doesn't feel like a robust approach. > I agree that supporting the standard mechanisms is highly desirable, but some sort of fallback poll timeout value is necessary on platforms where none of those mechanisms are supported. Arguably, some kernel configurability (whether via a kernel parameter, as proposed here, or some other means) is still desirable. I also agree there is no robust method to determine a "good value", but then again - how was the current value for the constant determined? As suggested in PATCH 2, the idea is to lower the global timeout to avoid hung tasks when devices break and never come back after reset. Linux already (partially) supports the _DSM methods you mention: - acpi_pci_add_bus() queries Function 8 (described in 4.6.8) to set ignore_reset_delay on the host bridge - pci_acpi_optimize_delay() uses Function 9 to set d3cold_delay and d3_delay in struct pci_dev, but does not currently store the DL_Up Time, FLR Reset Time and VF Enable Time I guess we can extend pci_struct akin to what PATCH 2 does to store all relevant delay values on a per-device basis, with some default value and overriding them as appropriate from Readiness Time Reporting, _DSM, or a quirk. Unfortunately, the hardware and firmware at my disposal does not support any of the discussed mechanisms, so I do not feel comfortable making the changes without being able to test them. Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879
