On Tue, 2012-02-14 at 10:34 -0600, Larry Finger wrote: > >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
