On Mon, Apr 11, 2016 at 10:56 AM, Mika Westerberg
<mika.westerberg@xxxxxxxxxxxxxxx> wrote:
> On Mon, Apr 11, 2016 at 03:36:41AM +0000, Zheng, Qi wrote:
>> > +static int pci_dev_check_d3cold(struct pci_dev *pdev, void *data) {
>> > + bool *d3cold_ok = data;
>> > +
>> > + /*
>> > + * The device needs to be allowed to go D3cold and if it is wake
>> > + * capable to do so from D3cold.
>> > + */
>> > + if (pdev->no_d3cold || !pdev->d3cold_allowed)
>> > + *d3cold_ok = false;
>> > + if (device_may_wakeup(&pdev->dev) && !pci_pme_capable(pdev, PCI_D3cold))
>> > + *d3cold_ok = false;
>> > +
>> > + return !*d3cold_ok;
>> >+}
>>
>> How about the pme_poll?
>> IMHO, if the pme_poll is set for some device, the PCIe port couldn't
>> go to sleep as well.
>
> I wasn't sure about that. If the device has pme_poll set, and the bridge
> is in D3 (or anything else than D0) the it will not be scanned for PME
> (this is done in pci_pme_list_scan()).
>
> My understanding is that pme_poll is a workaround for bridges which do not
> forward PME messages upstream properly. Since this whole thing is only
> enabled for recent PCIe hardware, I would expect that this works also :)
Fair enough, but we may need to do something about that in the future
if things turn out to not work properly.
--
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
