[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20151004151635.GC12684@xo-6d-61-c0.localdomain>
Date: Sun, 4 Oct 2015 17:16:35 +0200
From: Pavel Machek <pavel@....cz>
To: Alan Stern <stern@...land.harvard.edu>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Oliver Neukum <oneukum@...e.de>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Irina Tirdea <irina.tirdea@...el.com>,
Len Brown <len.brown@...el.com>,
Octavian Purdila <octavian.purdila@...el.com>,
Ulf Hansson <ulf.hansson@...aro.org>,
"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>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing
runtime suspend
Hi!
> > >
> > >> > This suggests we forget about power/wakeup == "off" and introduce an
> > >> > "inhibit" attribute instead.
> > >>
> > >> If we do that, can it still be regarded as a PM attribute?
> > >
> > > Why not? Consider this: Is there any reason to support inhibit when
> > > CONFIG_PM is disabled? I can't come up with any.
> >
> > Well, the "I don't want any input from you now, because the phone is
> > going into a pocket" case?
>
> But who would make a phone without CONFIG_PM? If you're sufficiently
> unconcerned about power usage that you turn off CONFIG_PM, then you
> probably don't care about getting excess input events either.
Well.. .excess input events means that your phone now sends (meaningful, thanks
to advanced predictions) messages to your friends...
Better not do that.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/
Powered by blists - more mailing lists