On Wed, Oct 15, 2008 at 10:47:48AM -0700, Marcel Holtmann wrote: > Hi Luis, > > > > I can see it useful when companies actually start building products with > > > two or more cards in the system and have different cards for different > > > tasks in it. So if you stick one card for one band and another one for > > > the other band in there, then it would make sense to do a per-band > > > regulatory hinting. > > > > Sure, but custom solutions can require custom regulatory dbs and > > people can do any crazy thing they want here, just as when they need > > custom regulatory domains not allowed by the FCC in the USA for > > example. Remember that by default the design is trying to cover the > > usual scenario of users with 1 wireless card or 2 with one built in. > > We decided on our discussions to respect the built-in card first. For > > more cards we can take the intersection if we want to keep being more > > restrictive. Its what makes sense if you think about it. > > I must admit that I never thought about the implications of multiple > bands with multiple hardware. I am not against keeping it simple and > forcing to have userspace in place to change it. However we do wanna > have support for old laptops that are currently working fine with no > extra userspace, but newer kernels where they just add the second card > to access an A-network. Also remember that internal cards can't really > be disabled most of the times. So you mean you worry about cases where people are using kernels >= 2.6.28 without crda and iw? If so then they can use for 2.6.28 the OLD_REGULATORY but the idea is for sure to push crda and iw for distributions definitley as of 2.6.29 for when OLD_REGULATORY is scheduled for removal. The problem here is not this though the problem here is the case where people are using 2.6.28 without no iw or crda *and* have more than two cards :) > > > Not sure if this really ever ends up in a product. However I can see the > > > case where you have a laptop with a BG-card and then attach an A-card to > > > it do access an A-network and then it doesn't work. It would be nice to > > > just have this working. Currently this would not work. > > > > Yes it does, it just doesn't work for your hardware as Intel put into > > regulatory hardware capability and these are two *very* different > > things. That is the problem. > > > > My suggestion is to add a default minimal 5 GHz regulatory domain > > definition to your driver on single band cards to deal with this. When > > a dual band card is present then all of the full card's capabilities > > will be used. > > That would be one option, but it sounds really strange to me that a > BG-card has to "think" about A-bands. Don't think about it that way -- instead think of it this way: Intel EEPROM is used for capability stuff but its now also being used for regulatory and that is what is limitting you. So you *can* think about 5 GHz band for a single 2.4 GHz band card, its just that your regulatory stuff right now is focused more on capabilities and not real regulatory. > Let not try to put this down into the drivers if we can solve this > nicely with a per-band regulatory hints inside the core. Good point. This is reasonable as well, perhaps if the regulatory hint has no 5 Ghz band channels it should not imply policy on it at all? Should be simple enough to fix too I think instead of having two regulatory_hint() calls per band. > > > Also the case when we unplug the first card, does the regulatory hint > > > gets reset and the next card could bring in a new one? I can see use > > > cases where you don't wanna use the built-in card, because it is just > > > too limited. > > > > For now nl80211 supports changing regulatory domains. > > Please keep in mind the case where we do have a new kernel with old > userspace or an userspace without CRDA. Sure, what do you think of the above? Luis -- 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
