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. > 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". johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
