archive mirror
 help / color / mirror / Atom feed
From: Mika Westerberg <>
To: "Rafael J. Wysocki" <>
Cc: Linux PCI <>,
	Linux ACPI <>,
	Linux PM <>,
	LKML <>,
	Bjorn Helgaas <>,
	Kai-Heng Feng <>,
	Utkarsh H Patel <>,
	Koba Ko <>
Subject: Re: [PATCH v2] PCI: PM: Add special case handling for PCIe device wakeup
Date: Thu, 29 Jul 2021 16:23:05 +0300	[thread overview]
Message-ID: <YQKruWMmSXeH3GL6@lahna> (raw)
In-Reply-To: <3149540.aeNJFYEL58@kreacher>

Hi Rafael,

On Wed, Jul 28, 2021 at 07:25:04PM +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <>
> Some PCIe devices only support PME (Power Management Event) from
> D3cold.  One example is the ASMedia xHCI controller:
>  11:00.0 USB controller: ASMedia Technology Inc. ASM1042A USB 3.0 Host Controller (prog-if 30 [XHCI])
>    ...
>    Capabilities: [78] Power Management version 3
>        Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0-,D1-,D2-,D3hot-,D3cold+)
>        Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
> In those cases, if the device is expected to generate wakeup events
> from its final power state, pci_target_state() returns D0, which
> prevents the PCIe hierarchy above the device from entering any
> low-power states too, but the device cannot signal PME from D0
> either.  However, if the device were allowed to go into D3hot, its
> parent PCIe port and its ancestors would also be able to go into D3
> and if any of them goes into D3cold, the device would end up in
> D3cold too (as per the PCI PM spec v1.2, Table 6-1), in which case
> it would be able to signal PME.
> This means that the system could be put into a lower-power
> configuration while meeting the requirement to enable the device to
> generate PME from the final state (which is not the case if the
> device stays in D0 along with the entire hierarchy above it).
> In order to avoid missing that opportunity, extend pci_pme_capable()
> to return 'true' in the special case when the target state is D3hot
> and the device can only signal PME from D3cold and update
> pci_target_state() to return the current target state if
> pci_pme_capable() returns 'true' for it.
> This change can be regarded as a pci_target_state() fix, because that
> function should ignore its 'wakeup' argument if signaling PME from
> any power states shallower than the current candidate one (including
> D0) is not supported.
> Link:
> Fixes: 666ff6f83e1d ("PCI/PM: Avoid using device_may_wakeup() for runtime PM")
> Reported-by: Mika Westerberg <>
> Reported-by: Utkarsh H Patel <>
> Reported-by: Koba Ko <>
> Signed-off-by: Rafael J. Wysocki <>

Tried this now and it fixes the issue! Also checked with another device
that actually supports PME from other states than D3cold and it also
works (as expected).

Feel free to add my,

Tested-by: Mika Westerberg <>


  reply	other threads:[~2021-07-29 13:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-28 17:25 [PATCH v2] PCI: PM: Add special case handling for PCIe device wakeup Rafael J. Wysocki
2021-07-29 13:23 ` Mika Westerberg [this message]
2021-07-29 13:44   ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YQKruWMmSXeH3GL6@lahna \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).