linux-kernel - [RFC][PATCH 0/3] PM / sleep: Avoid resuming runtime-suspended devices 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-next>] [day] [month] [year] [list]

Message-ID: <4649019.is79p6EySp@vostro.rjw.lan>
Date:	Tue, 13 May 2014 03:02:05 +0200
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Alan Stern <stern@...land.harvard.edu>,
	Linux PM list <linux-pm@...r.kernel.org>
Cc:	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	Aaron Lu <aaron.lu@...el.com>,
	Mika Westerberg <mika.westerberg@...ux.intel.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Kevin Hilman <khilman@...aro.org>,
	Ulf Hansson <ulf.hansson@...aro.org>
Subject: [RFC][PATCH 0/3] PM / sleep: Avoid resuming runtime-suspended devices during system suspend

Hi All,

We've discussed that at length here:

http://marc.info/?t=139950469000003&r=1&w=4

but I'm starting a new thread to refresh things a bit.

This is about adding a mechanism allowing us to avoid runtime-suspended
devices during system suspend.  The reason why it has to touch the PM core
is because that needs to be coordinated across the device hierarchy.

The idea is to add a new device PM flag and to modify the PM core as follows.

 - If ->prepare() returns a positive number for a device, that means "this
   device is runtime-suspended and you can leave it like that if you do the
   same for all of its descendants".

 - If that happens, the PM core sets the new flag for the device in
   question *if* the device is indeed runtime-suspended *and* *if*
   the transition is a suspend (and not hibernation, for example).
   Otherwise, it clears the flag for the device.  All of that happens in
   device_prepare().

 - In __device_suspend() the PM core clears the new flag for the device's
   parent if it is clear for the device to ensure that the flag will only
   be set for a device if it is also set for all of its descendants.

 - PM core skips ->suspend/late/noirq and ->resume/early/noirq for all devices
   having the flag set - so the flag can be called "direct_complete" as it
   causes the PM core to go directy for the ->complete() callback when set.

 - The ->complete() callback has to check direct_complete if ->prepare()
   returned a positive number previously and is responsible for further
   handling of the device.

That is introduced by patch [2/3].

To simplify things slightly it is helpful to move the invocation of
pm_runtime_barrier() from __device_suspend() to device_prepare(), but still
under pm_runtime_get_noresume() beforehand (patch [1/3]).

Patch [3/3] shows how this can be used by adding support for it to the ACPI
PM comain.

Thanks!

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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/