From: Johannes Berg <johannes@sipsolutions.net>
To: LKML <linux-kernel@vger.kernel.org>
Cc: Tomas Winkler <tomasw@gmail.com>,
Kay Sievers <kay.sievers@vrfy.org>, Greg KH <greg@kroah.com>,
David Woodhouse <dwmw2@infradead.org>
Subject: firmware loading vs. initrd
Date: Thu, 11 Mar 2010 14:39:34 -0800 [thread overview]
Message-ID: <1268347174.4142.11.camel@jlt3.sipsolutions.net> (raw)
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
next reply other threads:[~2010-03-11 22:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-11 22:39 Johannes Berg [this message]
2010-03-11 22:56 ` [PATCH] firmware class: export nowait to userspace Johannes Berg
2010-03-12 4:21 ` Kay Sievers
2010-03-12 4:46 ` Johannes Berg
2010-03-12 5:29 ` Kay Sievers
2010-03-29 15:57 ` Johannes Berg
2010-03-12 4:32 ` firmware loading vs. initrd Kay Sievers
2010-03-12 4:48 ` Johannes Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1268347174.4142.11.camel@jlt3.sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=dwmw2@infradead.org \
--cc=greg@kroah.com \
--cc=kay.sievers@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tomasw@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox