We carry this patch around since a while. Is it safe to increase the
timeout also in mainline?
References: https://bugzilla.novell.com/show_bug.cgi?id=74526
IPW2100 fails to load firmware when booting on battery; increasing the
timeout solves the problem.
diff -urNp linux-2.6.12/drivers/base/firmware_class.c linux-2.6.12.SUSE/drivers/base/firmware_class.c
--- linux-2.6.12/drivers/base/firmware_class.c 2005-08-05 11:36:43.908851520 +0200
+++ linux-2.6.12.SUSE/drivers/base/firmware_class.c 2005-08-05 11:41:23.737311128 +0200
@@ -30,7 +30,7 @@ enum {
FW_STATUS_READY,
};
-static int loading_timeout = 10; /* In seconds */
+static int loading_timeout = 30; /* In seconds */
/* fw_lock could be moved to 'struct firmware_priv' but since it is just
* guarding for corner cases a global lock should be OK */
--
short story of a lazy sysadmin:
alias appserv=wotan
On Saturday 21 January 2006 21:18, Olaf Hering wrote:
> We carry this patch around since a while. Is it safe to increase the
> timeout also in mainline?
>
> References: https://bugzilla.novell.com/show_bug.cgi?id=74526
>
> IPW2100 fails to load firmware when booting on battery; increasing the
> timeout solves the problem.
Not needed, can be adjusted from user space, once /sys is mounted.
echo -n 30 >/sys/class/firmware/timeout
The firmware class driver just provides a sane default, nothing else.
If this becomes a very common case (many drivers having big firmware
and userspace needs a lot of time providing it), your patch should go in.
But then the _default_ is wrong for many users.
Regards
Ingo Oeser