On Fri, May 13, 2016 at 01:15:31PM +0200, Lukas Wunner wrote:
> There are devices wich are not power-managed by the platform, yet can be
s/wich/which/
> runtime suspended to D3cold with some other mechanism. When putting the
> system to sleep, we currently handle such devices improperly by trying
> to transition them from D3cold to D3hot (the default power state defined
> at the beginning of pci_target_state()). Avoid that.
>
> An example for devices affected by this are Thunderbolt controllers
> built into Macs which can be put into D3cold with nonstandard ACPI
> methods.
>
> Signed-off-by: Lukas Wunner <lukas@xxxxxxxxx>
This needs an ack from Rafael.
Naive question: why is the default target_state PCI_D3hot?
> ---
> drivers/pci/pci.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 791dfe7..6af9911 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -1943,6 +1943,8 @@ static pci_power_t pci_target_state(struct pci_dev *dev)
> && !(dev->pme_support & (1 << target_state)))
> target_state--;
> }
> + } else if (dev->current_state == PCI_D3cold) {
> + target_state = PCI_D3cold;
> }
This only covers the case of !device_may_wakeup(). So I guess
device_may_wakeup() is false for these Thunderbolt controllers. Is
there a reason you don't want to do this check for devices that may
wakeup?
Sorry, more naive questions. I don't know anything about power
management, and it all looks like black magic to me.
> return target_state;
> --
> 2.8.1
>
> --
> 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
--
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
