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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Mon, 28 Jul 2014 13:01:14 -0700
From:	Patrik Fimml <>
To:	Dmitry Torokhov <>
Cc:	"Rafael J. Wysocki" <>,
	Alan Stern <>,
	Patrik Fimml <>,
	Bastien Nocera <>,,
	Benson Leung <>,,
Subject: Re: Power-managing devices that are not of interest at some point in

On Fri, Jul 18, 2014 at 04:16:50PM -0700, Dmitry Torokhov wrote:
> [...]
> Anyway, even though it is very tempting to declare inhibit a "deeper" state of 
> runtime suspend maybe you are right and inhibit should really be separate from 
> PM and drivers would have to sort out all the possible state permutations.
> Considering input devices:
> input_open(): check if device is inhibited, if so do nothing. Otherwise try 
> waking up itself and parent (via pm_runtime_get_sync() on itself), this will 
> power up the device. Do additional configuration if needed.
> input_close(): check if device is inhibited, if not do pm_runtime_put (_sync? 
> to make sure we power off properly and not leave device up and running? or 
> should we power down manually not waiting for runtime PM)?
> inhibit(): check if device is opened, if opened do pm_runtime_put_sync().
> uninhibit(): if device is opened do pm_runtime_get_sync(), let runtime PM 
> bring up the device. Do additional config if needed -> very similar to 
> input_open(), different condition.
> runtime_suspend(): power down the device. If not inhibited enable as wakeup 
> source.
> runtime_resume(): power up the device if device is opened and not inhibited.
> system_suspend(): check if device is opened, not inhibited and not in 
> runtimesuspend  already; power down.
> system_resume(): power up the device if it is opened and not inhibited. I 
> guess it's OK to wake up device that shoudl be runtime-PM-idle since it will 
> go to back sleep shortly.
> Ugh.. This is complicated...

There might be more elegant ways to implement this. It might make sense
to factor out power transitions. One could have a function that derives
the appropriate power state given the circumstances (i.e.
suspend/inhibit/runtime suspend) and then performs the needed
transition. This is something one would have to see when actually
implementing this, I might experiment with this approach a bit.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists