Am Dienstag, 25. März 2008 13:40:53 schrieb Rafael J. Wysocki: > On Tuesday, 25 of March 2008, Oliver Neukum wrote: > > Am Montag 24 März 2008 schrieb Rafael J. Wysocki: > > > + * after @prepare() returns. If @prepare() detects a situation it cannot > > > + * handle (e.g. registration of a child already in progress), it may return > > > + * -EAGAIN, so that the PM core can execute it once again (e.g. after the > > > + * new child has been registered) to recover from the race condition. This > > > + * method is executed for all kinds of suspend transitions and is followed > > > + * by one of the suspend callbacks: @suspend(), @freeze(), or @poweroff(). > > > > This could be understood so that disconnect() cannot be called. > > At what time exactly? I see no locking that would would prevent disconnect() in the window between prepare() and suspend()/... > > > + * The PM core executes @prepare() for all devices before starting to > > > + * execute suspend callbacks for any of them, so drivers may assume all of > > > + * the other devices to be present and functional while @prepare() is being > > > + * executed. However, they may NOT assume anything about the availability > > > + * of the user space at that time. > > > > Probably it should be mentioned that this is the time to allocate memory > > if you have to. > > Well, not exactly. Afterwards you cannot use GFP_KERNEL allocations, but > GFP_NOIO should still work, although for hibernation it's quite possible that > they'll fail if substantial amounts of memory are requested. > > > And it is too late to request firmware. > > Yes. This is better documented explicitly. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
