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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1442932301.6240.11.camel@suse.de>
Date:	Tue, 22 Sep 2015 16:31:41 +0200
From:	Oliver Neukum <oneukum@...e.de>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Irina Tirdea <irina.tirdea@...el.com>,
	Len Brown <len.brown@...el.com>,
	Octavian Purdila <octavian.purdila@...el.com>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Pavel Machek <pavel@....cz>,
	"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>
Subject: Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing
 runtime suspend

On Tue, 2015-09-22 at 10:15 -0400, Alan Stern wrote:
> On Tue, 22 Sep 2015, Oliver Neukum wrote:
> 
> > Indeed. We can handle output to suspended devices by waking them.
> > I don't see why this case is different. We are talking about input
> > only.
> > 
> > > The runtime-PM "usage" value for these devices is a little tricky to 
> > > calculate.  It should be nonzero if there are any open files _and_ the 
> > > device isn't "inhibited".  I don't know the best way to represent that 
> > > kind of condition in the runtime PM framework.
> > 
> > Does that make sense in the generic framework at all? I still
> > think that drivers should cease IO for input in such cases.
> > That should involve a common callback, but no counter.
> 
> I'm not sure I understand what you're saying.  Are you suggesting that
> this "inhibit" mechanism should involve a new callback different from

Yes, there is no necessary relation to power management. If you put
your phone into your pocket, you will want to inhibit the touchscreen
even if that doesn't save power.

> the existing runtime-PM callbacks?  And when this new callback is
> invoked, drivers should cancel existing input requests (these devices
> are input-only) and go to low power?

Cancel, yes, going to low power is a consequence which needn't bother
the power subsystem. You need a callback. If there are spurious
events, the current heuristics will keep devices awake.
You must discard them anyway, as they are spurious. There's no point
in transporting over the bus at all. We can cease IO for input.

> This would create a parallel runtime-PM mechanism which is independent
> of the existing one.  Is that really a good idea?

It isn't strictly PM. It helps PM to do a better job, but
conceptually it is independent.

	Regards
		Oliver



--
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/