Re: firmware loading vs. initrd

[Kay Sievers <kay.sievers@vrfy.org>]

On Thu, Mar 11, 2010 at 23:39, Johannes Berg <johannes@sipsolutions.net> wrote:
> 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.

I don't think we can reliably make the decision that the firmware is
not available at a later point.

Depending on the system, we can have several re-trigger of the same
events during bootup, and the firmware loader does not have any idea
in which state the system is.

What's wrong to leave the request staying around for forever, until it
is possibly canceled from userspace? So this event could be
re-triggered from userspace any time later. Whatever will cancel the
firmware requests in the end, it needs to be something that knows more
about the state of "booting" than the firmware loader knows today, I
guess.

Thanks,
Kay