[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 4 Apr 2007 08:06:05 -0700
From: David Brownell <david-b@...bell.net>
To: Alan Stern <stern@...land.harvard.edu>
Cc: Maxim Levitsky <maximlevitsky@...il.com>,
Ingo Molnar <mingo@...e.hu>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Greg KH <greg@...ah.com>, Thomas Gleixner <tglx@...utronix.de>,
Kernel development list <linux-kernel@...r.kernel.org>,
Linux-pm mailing list <linux-pm@...ts.osdl.org>
Subject: Re: [linux-pm] [PATCH v2] Add suspend/resume for HPET
On Monday 02 April 2007 1:04 pm, Alan Stern wrote:
> On Mon, 2 Apr 2007, David Brownell wrote:
> > This is the kind of thing that the pm_parent relationship was (AFAICT)
> > originally supposed to handle. Of course, it doesn't/can't, given the
> > current implementation ... that relationship is never used.
>
> Just so. In fact, there almost certainly are other dependencies that
> nobody is aware of, simply because they have never had a chance to bite.
In any given system, yes there are bugs lurking. But I was more concerned
with a provably wrong assumption made by the current framework. Such things
cause cascading fragility.
As Thomas mentioned, HPET isn't the only place where a "linear" model fails.
> Such things can be rather difficult to pin down when they occur. I would
> be happy enough to leave matters as they are, with a strict LIFO approach.
I wouldn't. Much better to have a solid handle on the interdependencies
than to need to cope, long term, with a framework that doesn't allow that.
Remember also that a LIFO model assumes that there's only one sequence by
which the hardware powers up/down ... i.e. that there's no runtime PM going
on, whereby large chunks are regularly powered down/up based on usage.
Better runtime PM becomes more important as system complexity rises.
- Dave
-
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