[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1204144570.15052.256.camel@pasglop>
Date: Thu, 28 Feb 2008 07:36:10 +1100
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: Alan Stern <stern@...land.harvard.edu>
Cc: Linux-pm mailing list <linux-pm@...ts.linux-foundation.org>,
Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: Fundamental flaw in system suspend, exposed by freezer removal
On Mon, 2008-02-25 at 10:39 -0500, Alan Stern wrote:
> Ongoing efforts to remove the freezer from the system suspend and
> hibernation code ("system sleep" is the proper catch-all term) have
> turned up a fundamental flaw in the Power Management subsystem's
> design. In brief, we cannot handle the race between hotplug addition
> of new devices and suspending all existing devices.
.../...
Yup, old problem, I think I've said a long time ago that it's the
reponsibility of bus drivers (such as USB khub) to stop issuing device
additions when suspend is in progress. It might be possible to still do
removal tho.
> The only possible solution is to have the drivers themselves be
> responsible for preventing calls to device_add() or device_register()
> during a system sleep. (It's also necessary to prevent driver binding,
> but this isn't a major issue.)
Agreed.
> The most straightforward approach is to
> add a new pair of driver methods: one to disable adding children and
> one to re-enable it. Of course this would represent a significant
> addition to the Power Management driver interface.
No, I think the global notifier is plenty for now. Later on, we can
re-add early-suspend, late-resume, or we can finally turn the whole
thing into a recursive call tree where the parents are the ones calling
the children suspend :-) But for now, I think the global notifier is
enough.
Cheers,
Ben.
--
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