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]

Date:	Sun, 27 Sep 2015 15:41:23 +0200
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Alan Stern <stern@...land.harvard.edu>
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 Saturday, September 26, 2015 11:20:50 AM Alan Stern wrote:
> On Sat, 26 Sep 2015, Rafael J. Wysocki wrote:
> 
> > > > 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
> 
> Cases where the driver wants to avoid runtime suspend (while the device
> is active) because of bad wakeup support in the hardware can be handled
> easily enough.  The runtime-idle or runtime-suspend callback routine
> can check whether wakeup == off; if it isn't then the callback should
> return -EBUSY.  Thus the driver can prevent runtime suspend without any
> need to increment the usage counter.

Right.

> > > That, or there may be an additional value, say "aggressive", to write to the
> > > control file in which case it becomes just
> > > 
> > > echo aggressive >/sys/.../power/control
> > 
> > That said I suppose that the "off" value for the "wakeup" file might also be
> > useful in some other cases, so it likely is a better approach.
> 
> We still need some sort of "inhibit" callback for cases where the
> driver doesn't want to go into runtime suspend but does want to turn
> off all I/O.  Should this callback be triggered when the user writes
> "off" to power/wakeup, or when the user writes "inhibit" to
> power/control, or should there be a separate sysfs attribute?

My first thought is that if there is a separate attribute, then it only actually
makes sense for devices that generate input events, while the "off" thing may
be generally useful in principle (eg. it may indicate to disable PME for the
device to the PCI layer etc).

OTOH, the additional "inhibit" attribute may only be exposed if the corresponding
callback is present, so I'm not really sure.

Question is, though, what's the use case for turning off I/O when we don't
go into runtime suspend.  After all, runtime suspend need not mean putting
the device into any kind of low-power state and the "off" thing may very
well be defined to mean that all input is discarded if the device is
runtime-suspended and the device is not configured to do remote wakeup
then.

Thanks,
Rafael

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