linux-kernel - [PATCH v8 0/4] Allow USB devices to remain runtime-suspended when sleeping

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <1443770071-2570-1-git-send-email-tomeu.vizoso@collabora.com>
Date:	Fri,  2 Oct 2015 09:14:27 +0200
From:	Tomeu Vizoso <tomeu.vizoso@...labora.com>
To:	linux-pm@...r.kernel.org, Alan Stern <stern@...land.harvard.edu>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	martyn.welch@...labora.co.uk, Ulf Hansson <ulf.hansson@...aro.org>
Cc:	Tomeu Vizoso <tomeu.vizoso@...labora.com>,
	David Airlie <airlied@...ux.ie>,
	Tomas Winkler <tomas.winkler@...el.com>,
	linux-usb@...r.kernel.org, linux-acpi@...r.kernel.org,
	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
	Russell King <linux@....linux.org.uk>,
	Len Brown <lenb@...nel.org>, Len Brown <len.brown@...el.com>,
	Kevin Hilman <khilman@...nel.org>,
	Tony Lindgren <tony@...mide.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-omap@...r.kernel.org, Pavel Machek <pavel@....cz>,
	linux-arm-kernel@...ts.infradead.org
Subject: [PATCH v8 0/4] Allow USB devices to remain runtime-suspended when sleeping

Hi,

this is v8 of an attempt to make it easier for devices to remain in
runtime PM when the system goes to sleep, mainly to reduce the time
spent resuming devices.

For this, we interpret the absence of all PM callback implementations as
it being safe to do direct_complete, so their ancestors aren't prevented
from remaining runtime-suspended.

Additionally, the prepare() callback of USB devices will return 1 if
runtime PM is enabled and the current wakeup settings are correct.

With these changes, a uvcvideo device (for example) stays in runtime
suspend when the system goes to sleep and is left in that state when the
system resumes, not delaying it unnecessarily.

Thanks,

Tomeu

Changes in v8:
- Add device_is_bound()
- Add dev_pm_domain_set() and update code to use it
- Move no_pm_callbacks field into CONFIG_PM_SLEEP
- Call device_check_pm_callbacks only after a device is bound or unbound

Changes in v7:
- Reduce indentation by adding a label in device_prepare()

Changes in v6:
- Add stub for !CONFIG_PM.
- Move implementation of device_check_pm_callbacks to power/main.c as it
  doesn't belong to CONFIG_PM_SLEEP.
- Take dev->power.lock before modifying flag.

Changes in v5:
- Check for all dev_pm_ops instances associated to a device, updating a
  no_pm_callbacks flag at the times when that could change.

Tomeu Vizoso (4):
  device core: add device_is_bound()
  PM / Domains: add setter for dev.pm_domain
  PM / sleep: Go direct_complete if driver has no callbacks
  USB / PM: Allow USB devices to remain runtime-suspended when sleeping

 arch/arm/mach-omap2/omap_device.c |  7 ++++---
 drivers/acpi/acpi_lpss.c          |  5 +++--
 drivers/acpi/device_pm.c          |  5 +++--
 drivers/base/dd.c                 | 12 ++++++++++--
 drivers/base/power/clock_ops.c    |  5 +++--
 drivers/base/power/common.c       |  8 ++++++++
 drivers/base/power/domain.c       |  6 ++++--
 drivers/base/power/main.c         | 33 +++++++++++++++++++++++++++++++++
 drivers/base/power/power.h        |  6 ++++++
 drivers/gpu/vga/vga_switcheroo.c  | 10 +++++-----
 drivers/misc/mei/pci-me.c         |  5 +++--
 drivers/misc/mei/pci-txe.c        |  5 +++--
 drivers/usb/core/port.c           |  6 ++++++
 drivers/usb/core/usb.c            | 11 ++++++++++-
 include/linux/device.h            |  2 ++
 include/linux/pm.h                |  1 +
 include/linux/pm_domain.h         |  3 +++
 17 files changed, 107 insertions(+), 23 deletions(-)

-- 
2.4.3

--
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/