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.1509211228290.1713-100000@iolanthe.rowland.org>
Date:	Mon, 21 Sep 2015 12:34:56 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
cc:	Pavel Machek <pavel@....cz>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Octavian Purdila <octavian.purdila@...el.com>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	"Tirdea, Irina" <irina.tirdea@...el.com>,
	Oliver Neukum <oneukum@...e.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Brown, Len" <len.brown@...el.com>
Subject: Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing
 runtime suspend

On Mon, 21 Sep 2015, Dmitry Torokhov wrote:

> On Mon, Sep 21, 2015 at 10:38:46AM -0400, Alan Stern wrote:
> > On Mon, 21 Sep 2015, Pavel Machek wrote:
> > 
> > > > > In fact, then, what you need seems to be the feature discussed by Alan
> > > > > and me some time ago allowing remote wakeup do be disabled for runtime
> > > > > PM from user space as that in combination with autosuspend should
> > > > > address your use case.
> > > > 
> > > > That, plus they want the touchscreen to go into runtime suspend 
> > > > whenever the screen is off (was this not the main reason for the 
> > > > patch?).
> > > > 
> > > > It seems to me that it should be possible to arrange for this to happen 
> > > > simply by making userspace close the touchscreen device when the screen 
> > > > is turned off.  Or am I missing something?
> > > 
> > > Well... that's not what existing userspace expects. Your X windows
> > > server will not close the touchscreen.
> > 
> > Surely that's a userspace issue, rather than a kernel problem?  The X
> > server does have some notion of power management and power savings; why
> > not extend that notion to include touchscreens?
> 
> It is not really practical: there are many consumers of input events, if
> we build infrastructure to control it and proxy all users through it,
> why not have it in kernel? Plus, there are users of input events
> directly in the kernel, such as legacy VT/keyboard, or Android/ChromeOS
> cpufreq_interactive governor that monitors user activity and bumps up
> CPU speed when user actively interacts with the device. They would keep
> input devices active even though user might not be actually able to
> use some input devices.

It sounds like you are suggesting there should be a general mechanism
for userspace to tell the kernel (or the input core) to ignore all
events from a particular input device -- or even from all input devices
-- thereby allowing those devices to go to low power.

I don't like to think of this as "forcing runtime suspend".  It's more
like telling the kernel that a device is no longer being used, so the
natural runtime PM mechanism can put it in runtime suspend.

Perhaps another way to think about it is that these input devices 
should not increment their runtime usage counter as part of the open 
routine; they should use something other than the number of open file 
references to indicate when they can go into runtime suspend.  (I'm not 
sure what else they should use, though.)

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/