On Monday 07 September 2009, Shaohua Li wrote:
> Hi,
>
> On Mon, Sep 07, 2009 at 01:01:14AM +0800, Rafael J. Wysocki wrote:
> > On Sunday 06 September 2009, Rafael J. Wysocki wrote:
> > > On Tuesday 01 September 2009, Shaohua Li wrote:
> > > ...
> > > > Updated patch.
> > >
> > > I looked at it and thought I would do it differently in many places, so
> > > below is my version.
> > +/*
> > + * Apparently, many BIOSes don't implement ACPI _OSC correctly, so let's not use
> > + * it by default.
> > + */
> > +static bool use_acpi_osc;
> I'd prefer _OSC is called by default, because without it PCIe PME might not work,
> chipset might have internal registers to change in the _OSC. Instead, if _OSC fails,
> we just ignore it by default.
OK
> > +/**
> > + * pcie_pme_handle_request - Find device that generated PME and handle it.
> > + * @port: Root port or event collector that generated the PME interrupt.
> > + * @req_id: PCIe Requester ID of the device that generated the PME.
> > + */
> > +static void pcie_pme_handle_request(struct pci_dev *port, u16 req_id)
> > +{
> > + u8 busnr = req_id >> 8, devfn = req_id & 0xff;
> > + struct pci_bus *bus;
> > + struct pci_dev *dev;
> > + bool found = false;
> > +
> > + bus = pci_find_bus(pci_domain_nr(port->bus), busnr);
> > + if (!bus)
> > + goto out;
> > +
> > + down_read(&pci_bus_sem);
> > + list_for_each_entry(dev, &bus->devices, bus_list) {
> > + pci_dev_get(dev);
> > + if (dev->devfn == devfn) {
> > + found = true;
> > + break;
> > + }
> > + pci_dev_put(dev);
> > + }
> > + up_read(&pci_bus_sem);
> > +
> > + if (found) {
> > + pm_request_resume(&dev->dev);
> Sounds we missed the case dev is PCIe-PCI bridge's (secondary bus, devfn 0). In such
> case we still need scan the legacy devices under PCIe-PCI bridge
Hmm. So, if devfn is zero and we find the device, we should go back to
bus->self rather than to scan devices on dev->subordinate, which is NULL.
Makes sense.
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
