linux-kernel - Re: Power-managing devices that are not of interest at some point in time

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.1407181107450.979-100000@iolanthe.rowland.org>
Date:	Fri, 18 Jul 2014 11:19:07 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
cc:	Dmitry Torokhov <dtor@...gle.com>,
	Bastien Nocera <hadess@...ess.net>,
	Patrik Fimml <patrikf@...omium.org>,
	<linux-pm@...r.kernel.org>, Benson Leung <bleung@...gle.com>,
	<linux-input@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: Power-managing devices that are not of interest at some point
 in time

On Fri, 18 Jul 2014, Rafael J. Wysocki wrote:

> > > the problem really seems to be that drivers are not
> > > aggressive enough with starting PM transitions (using runtime PM) when they
> > > see no activity.  Thus it seems that when the lid is closed, it'll be good
> > > to switch the drivers into a "more aggressive runtime PM mode" in which
> > > they will use any opportunity to start a power transition without worrying
> > > about extra latencies resulting from that.  In that mode they should also
> > > disable remote wakeup.  I think this should be sufficient to address the
> > > use case at hand.
> > 
> > OK, so how do we let the drivers know that they should start being aggressive 
> > with PM and that they should disable remote wakeup? I'd rather not add 
> > subsystem-specific interface for this, that is why we are reaching out in the 
> > first place.
> 
> For disabling remote wakeup we have a PM QoS flag that I'm not entirely happy
> with, so I guess we can replace it with something saner (I talked about that
> with Alan during the last year's LinuxCon, but then didn't have the time to
> get to that).

Right.  We discussed changing .../power/wakeup so that it could contain
"enabled", "disabled", or "off", where "off" would mean remote wakeup
should be disabled even during runtime suspend.

> For the whole thing I guess we can add a sysfs attribute under devices/.../power
> that will need to be exposed by drivers supporting that feature.  I'm not sure
> how to call it, though.

"runtime_mode"?

Will this really be capable of doing what Dmitry wants?  I don't know
how the drivers in question work.  But if a driver increments the
runtime usage count each time the device file is opened, forcibly
setting the usage count back to 0 won't be easy.

Also, would putting the camera into runtime suspend prevent it from
showing up on a list of available video devices?  I doubt it.  More
likely, the video driver would have to unregister the class device
while remaining bound to the physical device.  Probably other drivers
would have to do the same sort of thing.  (I don't know whether doing
this would retain the settings as Oliver wants, 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/