linux-kernel - Re: [linux-pm] [RFC] PCI: Runtime power management

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: <200908151618.10169.rjw@sisk.pl>
Date:	Sat, 15 Aug 2009 16:18:10 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	Alan Stern <stern@...land.harvard.edu>, linux-usb@...r.kernel.org,
	linux-pci@...r.kernel.org, Greg KH <gregkh@...e.de>,
	LKML <linux-kernel@...r.kernel.org>,
	"Linux-pm mailing list" <linux-pm@...ts.linux-foundation.org>
Subject: Re: [linux-pm] [RFC] PCI: Runtime power management

On Saturday 15 August 2009, Matthew Garrett wrote:
> On Fri, Aug 14, 2009 at 10:05:19PM +0200, Rafael J. Wysocki wrote:
> 
> > Well, sometimes the user may want a device to be power managed at run time
> > and not to be able to wake up the system from sleep states.  For example,
> > I'd like the USB controller in my box to be suspended at run time whenever it's
> > not used, but surely I wouldn't like it to do system-wide wakeup, because it
> > does that when I move the mouse which is a cordless one.  Simply turning the
> > mouse on causes the system to wake up. :-)
> 
> Right, so clearly my code is broken right now.
> 
> > Why don't we add a flag indicating whether or not the device is allowed to
> > be power managed at run time, something like runtime_forbidden, that the
> > user space will be able to set through sysfs?
> 
> I think even having a runtime_wakeup flag (which defaults to on) would 
> be sufficient.

Perhaps it would, but then unsetting runtime_wakeup would effectively disable
runtime PM for devices that need it to be power managed at run time (probably
all input devices).  Also there may be situations in which user space may
really want to disable runtime PM for some devices (think of broken hardware
for one example).

> If the worst case is scenario is that we have to resume 
> devices in order to apply the correct policy when going into a 
> systemwide suspend state, I think that's acceptable.

I agree.

Thanks,
Rafael
--
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/