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.1509211323540.1713-100000@iolanthe.rowland.org>
Date:	Mon, 21 Sep 2015 13:32:38 -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:

> > 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.
> 
> Yes. In ChromeOS we have a custim "inhibit" control that:
> 
> 1. Tells input core to ignore all events form a given device
> 2. Allows driver to put device in low power mode if driver desires to do
> so. The driver can do it via runtime PM or on it's own. Usually on it's
> own since when using runtime PM userspace may disable it, which may not
> be desirable.
> 
> I would love to have something generic instead of input-specific.
> 
> > 
> > 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.
> 
> I'd call it "accelerating" runtime suspend. Userspace tells the kernel
> that it intends not to use given device and kernel reacts accordingly.

Okay.

> > 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.)
> 
> I do not really want input specific support; as I mentioned before we
> have something like that in ChromeOS kernels but I was hesitant bringing
> it upstream as I believe it is not necessarily input device specific and
> I would love to have it implemented at device core level.

That's not a bad idea.  On the other hand, there must be lots of 
devices which would not be suitable for this.  Disk drives, for 
instance.

What happens if the "inhibit" control is turned on and the driver puts 
the device into runtime suspend, but then an I/O request arrives?

	If the I/O request originated from userspace, it means the
	user is violating the terms of the "inhibit" control.  Should
	the request simply fail?

	What if the I/O request originated from somewhere in the
	kernel, not from the user?

	Or maybe the driver would want to carry out the request,
	overriding the "inhibit" control temporarily.  Does it simply
	turn off the control, meaning that the device won't go back
	into runtime suspend until userspace turns the control on
	again?

	Or if the driver doesn't turn off the "inhibit" control, then
	how does it know when it can safely put the device back into
	runtime suspend?

Qustions like these make me think that this mechanism is best suited 
for a kind of device that doesn't handle I/O requests.  In other words, 
something that just reports events as they occur -- which is another 
way of describing an input device!

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/