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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.44L0.0902181006150.3186-100000@iolanthe.rowland.org>
Date:	Wed, 18 Feb 2009 10:09:25 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Arjan van de Ven <arjan@...radead.org>
cc:	Oliver Neukum <oliver@...kum.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	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, Arjan van de Ven wrote:

> 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, you're missing the point.  This part of the discussion is 
already focussed on your Step 2.  The question we are concerned with 
is: _How_ shall the driver and subsystem go about emulating the 
smartness?

Oliver's comment is a good one.  The principle of not suspending a
parent with active children has never been set in stone; with care we
should be able to circumvent it.

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/