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]

Date:	Tue, 22 Sep 2015 11:22:24 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Oliver Neukum <oneukum@...e.de>
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, 22 Sep 2015, Oliver Neukum wrote:

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

Going to low power needn't involve the power subsystem?  That sounds 
weird.

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

So my next question is: _How_ can this help PM to do a better job?  
That is, what are the mechanisms?

One you have already stated: Lack of spurious events will help prevent 
unwanted wakeups (or unwanted failures to go to sleep).

But Dmitry made a stronger claim: Inhibiting an input device should 
allow the device to go to low power.  I would like to know how we can 
implement this cleanly.  The most straightforward approach is to use 
runtime PM, but it's not obvious how this can be made to work with the 
current API.

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/