linux-kernel - Re: [PATCH v1 2/3] PM / sleep: try to runtime suspend for direct complete

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>] [day] [month] [year] [list]

Date:	Wed, 2 Mar 2016 10:26:44 +0100
From:	Ulf Hansson <ulf.hansson@...aro.org>
To:	"dbasehore ." <dbasehore@...omium.org>
Cc:	"Martin K . Petersen" <martin.petersen@...cle.com>,
	"James E . J . Bottomley" <JBottomley@...n.com>,
	linux-scsi <linux-scsi@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Len Brown <len.brown@...el.com>,
	"Rafael J . Wysocki" <rjw@...ysocki.net>,
	Pavel Machek <pavel@....cz>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 2/3] PM / sleep: try to runtime suspend for direct complete

On 2 March 2016 at 09:31, dbasehore . <dbasehore@...omium.org> wrote:
>
> On Mar 1, 2016 12:41, "Ulf Hansson" <ulf.hansson@...aro.org> wrote:
>>
>> On 25 February 2016 at 01:11, Derek Basehore <dbasehore@...omium.org>
>> wrote:
>> > This tries to runtime suspend devices that are still active for direct
>> > complete. This is for cases such as autosuspend delays which leaves
>> > devices able to runtime suspend but still active. It's beneficial in
>> > this case to runtime suspend the device to take advantage of direct
>> > complete when possible.
>>
>> Unfortunate this doesn't work. In the device_prepare() phase the PM
>> core prevents runtime suspend via a call to pm_runtime_get_noresume().
>>
>> Kind regards
>> Uffe
>>
>
> A call to pm_runtime_put_sync_suspend should work. We can't do this
> earlier, because we don't know if the device will actually use
> direct_complete due to its children. Calling pm_runtime_put_noidle may
> allow another pm_runtime_put to runtime suspend the device, but we're
> trying to do that anyways. Also, we can't just call ...put_sync since that
> might not suspend due to autosuspend delays.
>
> We just need to balance the call with another get_noresume after. Am I
> missing anything?

Yes.

The important part that you need to take into consideration is the
sysfs intererface for runtime PM of devices. It allows userspace to
prevent runtime PM suspend (pm_runtime_forbid()). Therefore, you
simply can not rely on the regular runtime PM APIs to put a device
into low power state during system PM.

In cases of a runtime PM centric subsystem/driver, it can instead use
pm_runtime_force_suspend().

Kind regards
Uffe