Hi all, We really should be asking Luis to look at this who hasn't yet chimed in, presumably because he's between jobs (and travelling IIRC) On Wed, 2013-12-18 at 10:16 +0100, Arend van Spriel wrote: > On 12/17/2013 11:06 PM, Linus Torvalds wrote: > > We have literally had this *exact* same issue with firmware loading. > > Network drivers shouldn't try to load firmware at module load time. > > Same deal. > > It is kind of a chicken and egg problem for (wireless) networking > drivers. To get IFF_UP from the network layer you have to register a > netdevice. For wireless drivers this means you have to register a wiphy > device with cfg80211 which flags capabilities and optionally are custom > regulatory domain. That information depends on the device and firmware > used. And there we have a full circle. This is all really beside the point. For this CRDA information, the kernel never actually *waits* for it, so in the case that there's no reply, it uses the built-in world domain. So it's not like request_firmware(), which will block boot forever, but it's also not like request_firmware_nowait() which will eventually time out and come back with an error if userspace isn't handling it (though now that firmware loading is built in ...) The issue is that it uses the built-in data *forever*, and what Sander said was "or it will block forever" but just meant that it never was able to do any further updates. It *doesn't* actually block the boot process or such. Everything Linus said is true but seems to have been written in understanding "blocks" as "blocking the boot process", rather than "blocking further updates". Regardless of this, even blocking further updates is a really bad idea. There are a few ways to handle this, but I'll let Luis poke at that. 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
