Messages in this thread | | | From | Dmitry Torokhov <> | Subject | Re: Totally broken PCI PM calls | Date | Mon, 11 Oct 2004 17:58:48 -0500 |
| |
On Monday 11 October 2004 05:28 pm, Benjamin Herrenschmidt wrote: > > A "hang" sounds like the pmcore bug I reported about a year ago... > > > > It's rather foolish of the PM core to use the same semaphore to > > protect system-wide suspend/resume operations that it uses to > > for mutual exclusion on the device add/remove (which suspend > > and resume callbacks did happily in 2.4) ... since it's routine to > > unplug peripherals on suspended systems! > > Definitely. One thing is: how to do it instead ? I've been thinking > about it for a while and am still wondering... do we want a list > mecanism with add/remove notifiers so the PM walk can keep in sync > with devices added/removed ? or should addition/removal be simply > postponed until the end of the sleep/wakeup process (I tend to vote > for that). >
Yes, I think that devices that failed to resume (and all their children) have to be moved by the core resume function into a separate list and then destroyed (again by the driver core). For that we might need to add bus_type->remove_device() handler as it seems that all buses do alot of work outside of driver->remove handlers. The remove_device should accept additional argument - something like dead_device that would suggest that driver should not be alarmed by any errors during unbind/ removal process as the device (or rather usually its parent) is simply not there anynore.
Just my $.02
-- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |