Re: [cfg80211 / iwlwifi] setting wireless regulatory domain doesn'twork.

From: Johannes Berg
Date: Wed Dec 18 2013 - 04:26:49 EST


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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/