On Sun, Oct 19, 2008 at 11:38 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Sun, 2008-10-19 at 23:33 -0700, Luis R. Rodriguez wrote: > >> Well the code specifically disregards secondary regulatory_hint()'s >> right now and we reviewed why -- we discussed it at OLS and agreed to >> go with the first one as that will usually be the built in one. That's >> why. The restrictive thing to do next to handle more cards better is >> to keep doing intersections. > > If we're going to disregard 5 GHz for the first hint if there's no > information on it, then we should take the first hint containing 5 GHz > information seriously imho. Sure but an issue here is that if we do deal with band-specific regulatory domain definitions we change the regulatory behavior from being "disallow everything first" to "allow everything first, disable everything in the band for which we encounter a rule in except what the rule allows". Since the regulatory definitions in db.txt are in KHz we are allowing it to grow as more technology pops up with support for more bands. I think the first approach was better. The current suggestion of only applying rules if a band reg definition is present is only to deal with a rare case. I think its better we try to handle that instead and keep our existing behaviour. 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
