linux-kernel - Re: [PATCH 2/2] PCI / PM: Resume runtime-suspended devices later during system suspend

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 24 Feb 2014 13:58:05 -0700
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
Cc:	Linux PM list <linux-pm@...r.kernel.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux PCI <linux-pci@...r.kernel.org>,
	Alan Stern <stern@...land.harvard.edu>
Subject: Re: [PATCH 2/2] PCI / PM: Resume runtime-suspended devices later
 during system suspend

On Sun, Feb 23, 2014 at 4:21 PM, Rafael J. Wysocki <rjw@...ysocki.net> wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
>
> Runtime-suspended devices are resumed during system suspend by
> pci_pm_prepare() for two reasons: First, because they may need
> to be reprogrammed in order to change their wakeup settings and,
> second, because they may need to be operatonal for their children
> to be successfully suspended.  That is a problem, though, if there
> are many runtime-suspended devices that need to be resumed this
> way during system suspend, because the .prepare() PM callbacks of
> devices are executed sequentially and the times taken by them
> accumulate, which may increase the total system suspend time quite
> a bit.
>
> For this reason, move the resume of runtime-suspended devices up
> to the next phase of device suspend (during system suspend), except
> for the ones that have power.ignore_children set.  The exception is
> made, because the devices with power.ignore_children set may still
> be necessary for their children to be successfully suspended (during
> system suspend) and they won't be resumed automatically as a result
> of the runtime resume of their children.
>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>

Acked-by: Bjorn Helgaas <bhelgaas@...gle.com>

You can merge these two via your tree if you want.  I don't have any
changes queued up for pci-driver.c.

Bjorn

> ---
>  drivers/pci/pci-driver.c |   33 +++++++++++++++++++++++++--------
>  1 file changed, 25 insertions(+), 8 deletions(-)
>
> Index: linux-pm/drivers/pci/pci-driver.c
> ===================================================================
> --- linux-pm.orig/drivers/pci/pci-driver.c
> +++ linux-pm/drivers/pci/pci-driver.c
> @@ -616,15 +616,11 @@ static int pci_pm_prepare(struct device
>         int error = 0;
>
>         /*
> -        * PCI devices suspended at run time need to be resumed at this
> -        * point, because in general it is necessary to reconfigure them for
> -        * system suspend.  Namely, if the device is supposed to wake up the
> -        * system from the sleep state, we may need to reconfigure it for this
> -        * purpose.  In turn, if the device is not supposed to wake up the
> -        * system from the sleep state, we'll have to prevent it from signaling
> -        * wake-up.
> +        * Devices having power.ignore_children set may still be necessary for
> +        * suspending their children in the next phase of device suspend.
>          */
> -       pm_runtime_resume(dev);
> +       if (dev->power.ignore_children)
> +               pm_runtime_resume(dev);
>
>         if (drv && drv->pm && drv->pm->prepare)
>                 error = drv->pm->prepare(dev);
> @@ -654,6 +650,16 @@ static int pci_pm_suspend(struct device
>                 goto Fixup;
>         }
>
> +       /*
> +        * PCI devices suspended at run time need to be resumed at this point,
> +        * because in general it is necessary to reconfigure them for system
> +        * suspend.  Namely, if the device is supposed to wake up the system
> +        * from the sleep state, we may need to reconfigure it for this purpose.
> +        * In turn, if the device is not supposed to wake up the system from the
> +        * sleep state, we'll have to prevent it from signaling wake-up.
> +        */
> +       pm_runtime_resume(dev);
> +
>         pci_dev->state_saved = false;
>         if (pm->suspend) {
>                 pci_power_t prev = pci_dev->current_state;
> @@ -808,6 +814,14 @@ static int pci_pm_freeze(struct device *
>                 return 0;
>         }
>
> +       /*
> +        * This used to be done in pci_pm_prepare() for all devices and some
> +        * drivers may depend on it, so do it here.  Ideally, runtime-suspended
> +        * devices should not be touched during freeze/thaw transitions,
> +        * however.
> +        */
> +       pm_runtime_resume(dev);
> +
>         pci_dev->state_saved = false;
>         if (pm->freeze) {
>                 int error;
> @@ -915,6 +929,9 @@ static int pci_pm_poweroff(struct device
>                 goto Fixup;
>         }
>
> +       /* The reason to do that is the same as in pci_pm_suspend(). */
> +       pm_runtime_resume(dev);
> +
>         pci_dev->state_saved = false;
>         if (pm->poweroff) {
>                 int error;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/