firmware loading vs. initrd

[Johannes Berg]

Hi,

We recently converted a few wireless drivers to use
request_firmware_nowait() in order to be able to load firmware from
probe. We would like to continue with that so we can load the firmware
before registering with any other subsystems, as we had discussed at the
wireless summit last year.

However, in actually trying this today, I noticed that there's a problem
with this. I made my drivers all built in, and then I ended up with it
not working because the firmware agent that was in my initrd was telling
[1], and the kernel that the firmware could not be found.

I thought of modifying the firmware agent in the initrd to not tell the
kernel it doesn't have it, but that is problematic when using
request_firmware(), the kernel boot will be delayed until the timeout
(one minute).

This can be solved by adding an environment variable to the uevent that
tells userspace whether or not this is coming from request_firmware() or
request_firmware_nowait(). I will follow up with a patch doing that.

Additionally, however, we need to make a change like below to the
firmware agent in order to not reply to asynchronous firmware loads
during the initrd stage. I'm not sure how to actually check that we're
running in an initrd (is that possible?) nor did I actually verify that
the NOWAIT environment variable is set properly.

Thoughts? It seems like this would solve our problems nicely if we can
determine whether we're in the initrd or not.

johannes

--- /lib/udev/firmware.agent	2010-02-18 16:40:39.000000000 -0800
+++ firmware.agent	2010-03-11 12:00:40.000000000 -0800
@@ -21,6 +21,16 @@
     exit 0
 done
 
+if [ "$NOWAIT" = "1" ] && [ INITRD? ] ; then
+	# Leave the request open in case we are
+	# running from initrd -- we'll deal with
+	# it when we process things again after
+	# the root filesystem is mounted.
+
+	# exit 1 instead?
+	exit 0
+fi
+
 # the firmware was not found
 echo -1 > /sys/$DEVPATH/loading
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/