Re: firmware loading vs. initrd

[Johannes Berg <johannes@sipsolutions.net>]

On Fri, 2010-03-12 at 05:32 +0100, Kay Sievers wrote:
> 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.

Oh, interesting, I had no idea.

> 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.

Nothing in particular, although when you've set the timeout to 0 (no
timeout) this would have the request and a kernel thread stick around
forever. But I didn't know about multiple stages etc. here, so yes it
would probably make sense to just leave the request around until we know
we can reliably say we don't have it.

johannes