On Tue, Dec 4, 2012 at 10:41 AM, Johannes Berg
<johannes at sipsolutions.net> wrote:
> On Tue, 2012-12-04 at 10:28 -0800, Luis R. Rodriguez wrote:
>
>> >> This was a side effect of the checks we have in place, it was not expected.
>> >
>> > But this is what happens due to the reg.c implementation -- it checks
>> > that the freqband into which the primary and secondary channel fall each
>> > allows 40 MHz, even if they are two different freqbands.
>>
>> As I implemented it, it should be checking if HT40 is used. If so then
>> it should be checking to see if the primary can use 40 MHz bandwidth
>> and then check to see if the secondary can use 20 MHz. The issue
>> should be that the code should likely is checking that the secondary
>> requires 40 MHz. It should only need to check if the secondary can use
>> 20 MHz if HT40 is desired.
>
> I don't think this is really what we should do ... In fact given the way
> we do it now with overlapping freqbands this would cause more problems
> than it would solve, I think.
If we end up supporting overlapping frequency rules to be submitted.
Right now they don't overlap but point taken that we do support it and
there may possible issue of having them supported.
> What it really should check is that for each freqband, as much bandwidth
> is allowed as falls into that freqband. But given that we have
> overlapping freqbands, much bandwidth will actually fall into each one
> of them, so we must allow @40 again ...
>
> I'm drawing some pictures now :-)
:) Lets be clear though that your points on overlapping frequency
rules are a separate architectural position to take than addressing
the issue at hand. This however is a good crux point for us to
evaluate this particular architectural consideration.
>> > Indeed this is what we had, but I built the db.txt parser based on the
>> > assumption that in fact "@ 20" in the channel 11/12 freqband would have
>> > been sufficient to allow 40 Mhz on channel 9+. This isn't the case in
>> > the kernel implementation today.
>>
>> I'll fix that, but given you have a slew of updates not sure if this
>> should go in after / before your changes.
>
> I think the easiest for now would be to actually do what's implemented
> and make this change to dbparse.py:
>
> @@ -162,9 +164,6 @@ class DBParser(object):
> self._syntax_error("Inverted freq range (%d - %d)" % (start, end))
> if start == end:
> self._syntax_error("Start and end freqs are equal (%d)" % start)
> - if end - start < bw:
> - self._syntax_error("Invalid bandwidth: %d width channel "
> - "cannot possibly fit between %d - %d" % (bw, start, end))
> except ValueError:
> self._syntax_error("band must have frequency range")
>
>
> Then we can make the db.txt change I suggested in the the original patch
> in this thread and keep the rules that both the primary and secondary
> channel must be in a freqband that allows 40 MHz.
Sure, we would just need to document this.
> Note that this really only applies for the 00 world roaming regdomain
> (and maybe Japan, but I don't actually think so) since every other
> regdomain just uses a single rule.
Sure.
Luis
