[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.0804141043001.2236-100000@iolanthe.rowland.org>
Date: Mon, 14 Apr 2008 10:49:26 -0400 (EDT)
From: Alan Stern <stern@...land.harvard.edu>
To: Benjamin Herrenschmidt <benh@...nel.crashing.org>
cc: "Rafael J. Wysocki" <rjw@...k.pl>, Greg KH <greg@...ah.com>,
pm list <linux-pm@...ts.linux-foundation.org>,
ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
Len Brown <lenb@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Alexey Starikovskiy <astarikovskiy@...e.de>,
David Brownell <david-b@...bell.net>,
Pavel Machek <pavel@....cz>, Oliver Neukum <oliver@...kum.org>,
Nigel Cunningham <ncunningham@...a.org.au>,
Jesse Barnes <jbarnes@...tuousgeek.org>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 1/3] PM: Introduce new top level suspend and hibernation
callbacks (rev. 8)
On Mon, 14 Apr 2008, Benjamin Herrenschmidt wrote:
>
> > To avoid breaking things (from the functional point of view) unnecessarily.
> >
> > In short, I don't really see the difference between moving ->prepare() before
> > the freezer and droppig the freezer, which I'm not going to do right now.
>
> I believe the use of prepare for things like request_firmware etc... is
> worth the effort of fixing the known breakage of not having the freezer
> while preventing insertion of new devices (mostly USB).
I used USB as an example simply because that's what I'm familiar with.
Don't be so quick to assume the rest of the kernel is trouble-free.
> In fact, it
> won't be such a big issue as the core should/will return an error from
> attempting to add the device in that case.
But it _would_ be a regression -- and everyone knows how much Linus and
Andrew dislike regressions. :-)
Now, I don't see what the big deal is here. We all agree that it would
be nice and appropriate if drivers could do things like
request_firmware() during prepare(). But for the moment they can't.
It's not like this is some tremendous hardship -- you aren't going to
have to rip out all the existing prepare() implementations and rewrite
them, because they don't exist yet!
All it means is that the full conversion to the new interface will be a
multi-step process. Right now we add the new callbacks. Later on we
make it safe to move the freezer after prepare. Later still we
eliminate the freezer altogether from suspend. (Hibernation is a
separate matter...)
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/
Powered by blists - more mailing lists