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: <20090218065158.5efa8536@infradead.org>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ