linux-kernel - Re: [RFD] Automatic 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:	Wed, 18 Feb 2009 06:51:58 -0800
From:	Arjan van de Ven <arjan@...radead.org>
To:	Oliver Neukum <oliver@...kum.org>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Alan Stern <stern@...land.harvard.edu>,
	pm list <linux-pm@...ts.linux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Arve Hjønnevåg <arve@...roid.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Pavel Machek <pavel@....cz>,
	Nigel Cunningham <nigel@...el.suspend2.net>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	mark gross <mgross@...ux.intel.com>,
	"Woodruff, Richard" <r-woodruff2@...com>,
	Uli Luckas <u.luckas@...d.de>,
	Igor Stoppa <igor.stoppa@...ia.com>,
	Brian Swetland <swetland@...gle.com>,
	Len Brown <lenb@...nel.org>
Subject: Re: [RFD] Automatic suspend

On Wed, 18 Feb 2009 09:53:48 +0100
Oliver Neukum <oliver@...kum.org> wrote:

> Am Wednesday 18 February 2009 00:26:53 schrieb Rafael J. Wysocki:
> > > Another possibility is to set up independent runtime PM for the
> > > transport and the device.  This means allowing the possibility
> > > that the transport is suspended while its child (the device) is
> > > not.  This is a little simpler (there's only one idle-timeout per
> > > device, since the link is treated as an independent device), but
> > > it violates the principle of never suspending a parent while
> > > there is an active child.
> > 
> > Well, I think the first approach would be better.
> 
> I am afraid it wouldn't be. How do you deal with shared transports?
> 

realistically, something like this you need to design like this
Step 1) Assume the hardware is smart and can do this for you on the fly,
        but it might need guidance.
        (For many busses there are platforms that do this)
Step 2) For hardware that is not smart, emulate the smartness in the
        driver, with help of the subsystem. These two together have
        the right knowledge to make such decisions.


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
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/