On Tue, 2012-02-14 at 10:34 -0600, Larry Finger wrote:

quoted

quoted

When the callback routine is used to launch a second request,
the structure gets messy, particularly with b43legacy, which loads 4
firmware files for some hardware. My solution is to create a delayed work
queue that is started in the probe routine with a delay of one second. The
routine that is triggered does the normal request_firmware() calls
and starts mac80211 when the firmware is available.

I suppose this works, but I'd be a little worried that when the driver
is built into the kernel it doesn't help much. I'm asking the udev
people to not answer async loads while in initramfs, but they'd still
give you a negative answer here, and they won't be able to tell the
difference between a synchronous request from a work item (which doesn't
block boot) and a synchronous request from probe (which does block
booting).

I asked a variant of this question on LKML and the driverdevel ML, but got no 
answer.

Unless I get a definitive answer, I'll have to go back to the chain loading, no 
matter how messy.

I'm not even sure they've done *anything* until now, so I'm not sure it
matters. I believe the behavioural change that prompted these changes
will actually make it easier to implement the delay in a matter that
covers both this and async loading, so you may well be safe, I haven't
really understood the full details of the change that prompted all this.

johannes