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]

Message-ID: <5611777.bNi5p029gt@vostro.rjw.lan>
Date:	Thu, 17 Jul 2014 01:11:31 +0200
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Patrik Fimml <patrikf@...omium.org>
Cc:	linux-pm@...r.kernel.org, Dmitry Torokhov <dtor@...gle.com>,
	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 Tuesday, July 15, 2014 06:32:06 PM Patrik Fimml wrote:
> (Re-sending with correct mailing list addresses.)
> 
> Hi,
> 
> When the lid of a laptop is closed, certain devices can no longer
> provide interesting input or will even produce bogus input, such as:
> 
> - input devices: touchscreen, touchpad, keyboard
> - sensors: ambient light sensor, accelerometer, magnetometer
> - a video camera mounted on the lid
> - display backlight
> 
> Various workarounds cover some of these cases, and we have some ugly
> hacks in ChromeOS to make things work. It would be nice if a userspace
> power management daemon could listen to the lid-close event, and then
> have a way to temporarily power off these devices, potentially through
> sysfs.
> 
> I've been discussing this with Dmitry and Benson (cc'd), and we've been
> wondering whether we could come up with a generic solution that could
> benefit multiple device classes.
> 
> There's some overlap with runtime PM here. The action to be taken in
> such a situation would probably be similar to a runtime suspend. The
> match is not perfect though, since devices with more than two power
> states might want to enter different states depending on the situation.
> 
> It's somewhat difficult to get the semantics right, since handles to
> such devices might still be open. It might be easier to implement
> behavior specific to device classes. On the other hand, it would be nice
> to have a uniform way of shutting devices down, and not introduce
> another possible path for a device to enter a power-saving state.
> 
> Rafael, can you give us your opinion on this?

Let me try to understand the scenario in the first place.

To start with, a number of devices is in use (that is, open, there are
applications listening/talking to them etc).  Now, an event happens, such
as a laptop lid close and you want some of those devices, but possibly
not all of them, to quiesce themselves and go into low-power states.

Is that correct?

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/