On Sun, Mar 22, 2009 at 1:28 AM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Sat, 2009-03-21 at 12:46 -0700, Luis R. Rodriguez wrote: > >> > country JP: >> > (2402.000 - 2472.000 @ 40.000), (N/A, 20.00) >> > (2457.000 - 2482.000 @ 20.000), (N/A, 20.00) >> > (2474.000 - 2494.000 @ 20.000), (N/A, 20.00), NO-OFDM > >> > Also, how >> > should the 2.4GHz part be interpreted? >> >> Channels 1-11 allow 40 width channels, so HT40 is allowed. >> Channels 12, 13 only allow 20 MHz width channels, so HT40 is disallowed. >> Channel 14 only allows OFDM. > > s/OFDM/non-OFDM/ > > Ok, this is a bit of a problem. Let me break out of this thread and > propose new, slightly changed, interpretation rules. > >> > Currently we are not interpreting overlapping ranges properly at all -- >> > we really need to fix a set of interpretation rules. >> >> Sort of, we currently stick to the first reg rule which fits our >> desired bandwidth. Right now we iterate through 2 possible max >> bandwidths -- 40 and 20 and then set the channel max bandwidth based >> on which one fits. Note though that we do disregard the freq_range max >> bandwidth, which my patches correct. > > True. I'm rather keen on removing that code though -- it is rather > confusing to hardcode 20/40 in there and try them. Agreed, which is why I got rid of them in my patches too. >> We also need to consider for future usage custom bandwidths, which I >> guess why we had the first JP rule for 4 GHz (but yeah the second rule >> seem to imply what the first one intends on allowing). First step >> might be to say allow drivers to use monitor mode with 10 MHz >> bandwidth or 5 MHz bandwidth. That of course would also need further >> work other than regulatory. > > Indeed. The question is how we want to capture this. So far I was always > thinking that we would capture this as an extra channel type -- like > HT40+, but going the other direction -- "10MHZ"/"5MHZ". That would work. 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
