On Wed, Nov 5, 2014 at 1:57 PM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote: > > It's relatively common to start with a pci_dev and look for an ACPI handle > that corresponds to that device or the closest enclosing scope, so maybe > there should be a way to do that directly. > > For pci_get_hp_params(), I think the current code is actually slightly > buggy because we don't look for _HPP/_HPX on the device itself; we only > look at the bridges upstream from it. > > What I had in mind was something like the following (untested and not for > application). > + * Search for an ACPI handle. The PCI device itself may have one, or an > + * upstream device (either a PCI-to-PCI bridge or a PCI host bridge) may > + * have one. > + */ > +acpi_handle pci_find_acpi_handle(struct pci_dev *pdev) > +{ > + struct device *dev; > + acpi_handle handle; > + struct pci_bus *bus; > + > + dev = &pdev->dev; > + handle = ACPI_HANDLE(dev); > + while (!handle) { > + pdev = pci_physfn(pdev); I'm a little worried about to apply hpx value for PFs to VFs. > + bus = pdev->bus; > + if (pci_is_root_bus(bus)) > + dev = bus->bridge; > + else { > + pdev = bus->self; > + dev = &pdev->dev; > + } > + handle = ACPI_HANDLE(dev); > + } > + return handle; > +} Also found another problem, pci_device_add==>pci_configure_device==>program_hpp_type2() path. and program_hpp_type2() will check dev->subordinate(). but at the time child bridge is not scanned yet. Maybe we should move pci_configure_device later ? Yinghai Lu -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html