On Sunday, 27 May 2007 23:49, Kay Sievers wrote: > On 5/27/07, Matthew Garrett <[EMAIL PROTECTED]> wrote: > > On Sun, May 27, 2007 at 10:31:53PM +0200, Rafael J. Wysocki wrote: > > > From: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > > > Use a hibernation and suspend notifier to disable the firmware requesting > > > mechanism before a hibernation/suspend and enable it after the operation. > > > > This avoids the problem of .resume methods calling userspace while > > userspace is frozen and a resulting hang, but does it actually result in > > the drivers beginning to work again? If we remove process freezing in > > STR, this should just work[1] without the need to complicate things. On > > the other hand, if we don't want to support these functions in the > > suspend and resume methods we could just audit the kernel and remove > > them all. > > What exactly is the problem we see here? The timeout of the firmware loader? > What goes wrong with frozen userspace, usually there is only a netlink > message sent from the kernel, which should be received and handled > just fine when userspace is running again.
Users report the timeout as a problem and it's not that straightforward to figure out what happens. Still, I agree it's much better if drivers don't use request_firmware() in their .resume() routines at all, because they shouldn't rely upon user land at this point. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
