On Mon, Nov 23, 2009 at 12:13:09PM +0100, Johannes Berg wrote: > > I was wondering if we should really make the support for each chip a > > different kernel module as you did in your patch, but then I figured > > that this might be a good way to let the user choose whether to load > > AP or STA firmware if we have both available, which was still one of > > the unsolved problems. I.e., make mwl8366_ap and mwl8366_sta, and > > then let the user choose which one to load. Or is there a better way > > of doing this? > > Try to load both at probe() time (via the async firmware loading > interface that I fixed up recently [1], that patch will be in .33), and > hang on to the firmware images [2]. Register the wiphy with appropriate > bits depending on which firmware files you found (and fail + unbind if > you didn't find any, cf. my ar9170 patch [3]). Then you can upload the > right firmware depending on the type of interface the user is adding. This has the problem that e.g. if someone creates a STA interface first, and we load the STA firmware image in response to that, and then creates an additional AP interface, we'd have reload the chip while there's still an active interface (the original STA one), which seems somewhat involved. Just rejecting the second add_interface() seems undesirable, as then the outcome of two add_interface() calls will depend on their order. (AP firmware supports both AP and STA interfaces, but e.g. it doesn't do STA power save and such.) It'll also have some consequences if there are monitor interfaces, as e.g. STA firmware allows fine-grained control over the receive filter, while the AP firmware does not. -- 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
