| Message ID | 20140912180415.1630.57583.stgit@bhelgaas-glaptop2.roam.corp.google.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index cb411fbb6435..290c657da0b9 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -1358,9 +1358,6 @@ static void pci_configure_device(struct pci_dev *dev) struct hotplug_params hpp; int ret; - if (system_state == SYSTEM_BOOTING) - return; - memset(&hpp, 0, sizeof(hpp)); ret = pci_get_hp_params(dev, &hpp); if (ret)
There's not really a good way to determine whether firmware has already configured a device with _HPP/_HPX settings. On legacy systems, the BIOS has probably configured everything, but on UEFI systems it is not required to do so. Per the PCI Firmware Specification, rev 3.1, sec 3.5, if PCI_COMMAND_IO or PCI_COMMAND_MEMORY is set, we can assume firmware has set the corresponding BARs and maybe we can assume it has configured the rest of the device. And if a bridge has PCI_COMMAND_PARITY or PCI_COMMAND_SERR set, we can assume firmware has configured the bridge. But we can't tell much about devices without BARs. I think it should be safe to apply _HPP and _HPX settings anyway, even if firmware has already configured the device, so configure everything we find. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> --- drivers/pci/probe.c | 3 --- 1 file changed, 3 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html