[lkml]   [2010]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: firmware loading vs. initrd
On Fri, 2010-03-12 at 05:32 +0100, Kay Sievers wrote:
> On Thu, Mar 11, 2010 at 23:39, Johannes Berg <> 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.


 \ /
  Last update: 2010-03-12 05:51    [W:0.053 / U:3.492 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site