linux-kernel - Re: Power-managing devices that are not of interest at some point in time

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:	Fri, 18 Jul 2014 15:00:46 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Patrik Fimml <patrikf@...omium.org>
cc:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Dmitry Torokhov <dtor@...gle.com>,
	Bastien Nocera <hadess@...ess.net>, <linux-pm@...r.kernel.org>,
	Benson Leung <bleung@...gle.com>,
	<linux-input@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: Power-managing devices that are not of interest at some point
 in time

On Fri, 18 Jul 2014, Patrik Fimml wrote:

>  2. Give userspace a way of quiescing a device. Handles to the device
>     stay open, but the device will no longer perform its function and,
>     if possible, power down.

"Quiescing" is the wrong word.  "Quiescing a device" means stopping the
device from doing anything, which isn't what you want.  You want to
ignore any activity the device may generate and reduce the device's
power consumption as much as possible.  A better word would be
"deactivating".

> For input devices, this makes a lot of sense in my opinion.

I agree.

> The notable difference to runtime PM as we have it today is that with
> runtime PM, a device typically goes to a low-power state because it is
> idle. In our scenario, we want to forcibly quiesce it even if it is not
> idle (and if it continues to provide events in a low-power mode, we
> want to ignore them instead of passing them on). So maybe integration
> with runtime PM is not the best fit.
> 
> Perhaps the best way to go forward would be to add a new property for
> all devices that support quiescing so userspace has a uniform way of
> doing things, but have subsystems (and potentially the device driver)
> decide what action is appropriate to quiesce a device. Some subsystems
> might be able to provide a default implementation (e.g. input could just
> skip all events that are reported from the device driver).

You mentioned that handles to the device would remain open.  So when 
the user opens the lid again, the old handles would start functioning, 
right?

This has the disadvantage that the class device could not be
unregistered, because doing so would invalidate the open handles.  
Under such circumestances, how would a userspace video program know not
to list a camera built into the lid among the possible video sources
(an example given earlier in this discussion)?  The program would have
to make an explicit test of the "deactivate" property -- it wouldn't
automatically become aware that the camera wasn't available.

Would it sometimes be okay to unregister the class device and
invalidate the old handles, forcing programs to open new handles when
the lid is opened?  This would reduce the number of changes user 
programs would need.

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/