Re: [RFC][PATCH -mm 3/3] PM: Disable _request_firmware before hibernation/suspend

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 28 May 2007, at 08:43, Rafael J. Wysocki wrote:

Seems, that's just the broken synchronous firmware loading interface
with the useless timeout handling. The nowait version of the same loader
doesn't time out, and should not have that problem. The sync version
should be removed from the kernel, it just causes all sorts of problems
since it exists.

Userspace should handle the async request just fine when it comes back
running, regardless of the time it was submitted.

Okay, so the solution is to convert the drivers to use
request_firmware_nowait() instead of request_firmware() in their .resume()
routines.

[added Rob Landley to CC]

I think asynchronous loading should be made the default behaviour. However, we need to think and document how to do firmware loading.

Firmware loading can be done at two different times:
Device Driver Load
First use of Device Driver

For a network device, this correlates to when the driver is first loaded into memory or at 'ifconfig up' respectively.

At device driver load, firmware loading must be asynchronous. This is because device driver init can occur before userspace runs and registers a hotplug/uevent event handler. If device use is attempted before firmware loads, a -ENOFIRMWARE call would be great so that userspace and thus the user can be clearly informed what the problem is.

However, at 'first use' firmware loading, the synchronous interface should remain. 'ifconfig up' either works or it doesn't, and as I see it, has to just hang around until firmware turns up.

One more thing, it seems that the asynchronous firmware loading thread just spawns a _request_firmware() call which then times out at 60 seconds. I think, if the first request fails it spawns another. 60 seconds is *far* too long for this type of thing, and this was set at 10 seconds before the last two kernel releases (which is even a bit slow itself). Unfortunately, this appears to a case of quite senior kernel developers pushing a bodge upstream rather than fixing the underlying issue :( [1] [2]

Documentation for how hotplug/uevent handlers should cope with these types of firmware loading is also *strongly* requested, in order for lightweight but fully functional implementations to be made.

Documentation > Reference Implementation :)

Michael-Luke

[1] http://tinyurl.com/2colng (git.kernel.org)
[2] http://tinyurl.com/224h54 (redhat bugzilla)

_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux