linux-kernel - Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <Pine.LNX.4.44L0.1509251651320.1847-100000@iolanthe.rowland.org>
Date:	Fri, 25 Sep 2015 17:13:04 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
cc:	Oliver Neukum <oneukum@...e.de>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Irina Tirdea <irina.tirdea@...el.com>,
	Len Brown <len.brown@...el.com>,
	Octavian Purdila <octavian.purdila@...el.com>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	Pavel Machek <pavel@....cz>,
	"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>
Subject: Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing
 runtime suspend

On Fri, 25 Sep 2015, Rafael J. Wysocki wrote:

> On Friday, September 25, 2015 10:29:55 AM Alan Stern wrote:
> > On Fri, 25 Sep 2015, Rafael J. Wysocki wrote:
> > 
> > > We are missing the "no remote wakeup" bit now (well, there is a PM QoS flag,
> > > but it isn't very useful, so I'd prefer to replace it with a "no remote wakeup"
> > > bit in struct dev_pm_info or something similar).
> > > 
> > > That is actually quite important, because (a) we can save energy but not
> > > configuring the device to do remote wakeup in the first place and (b) that
> > > may involve more than just the driver (for example, disabling PCI or ACPI
> > > remote wakeup involves the bus type or similar).
> > > 
> > > So it looks like we need to be able to distinguish between "runtime suspend
> > > with remote wakeup" and "runtime suspend without remote wakeup".
> > > 
> > > And if we do the latter, we may not even need the "inhibit" thing any more,
> > > because suspended devices without that are not configured to do remote wakeup
> > > cannot really signal anything in the majority of cases.
> > 
> > That works only for drivers that use autosuspend to go to low power in
> > between events.  It doesn't work for drivers that remain at full power 
> > as long as the device file is open.  That kind of driver does require 
> > an "inhibit" interface.
> 
> Or an interface allowing user space to trigger pm_request_idle() for them.
> 
> So user space would change the "no remote wakeup" setting and then do the
> "try to suspend now" thing.

So something like:

	echo on >/sys/.../power/control  (in case the device was
			already in runtime suspend with wakeups enabled)
	echo off >/sys/.../power/wakeup
	echo auto >/sys/.../power/control

This should work.  But it would require that the driver doesn't
increment the usage counter when the device file is opened.  I can
imagine this might lead to trouble if you're dealing with hardware that
doesn't support remote wakeup very well.  The driver wouldn't be able
to work around the hardware issue by incrementing the usage counter.

In real life this might not be a serious issue.  I don't know.

Alan Stern

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