[wireless-regdb] [PATCH] regdb: allow 40 MHz on world roaming channels 12/13

[Luis R. Rodriguez]

On Tue, Dec 4, 2012 at 10:20 AM, Johannes Berg
<johannes at sipsolutions.net> wrote:
> On Tue, 2012-12-04 at 10:13 -0800, Luis R. Rodriguez wrote:
>
>> >> When in world roaming mode, allow 40 MHz to be used
>> >> on channels 12 and 13 so that an AP that is, e.g.,
>> >> using HT40+ on channel 9 (in the UK) can be used.
>> >
>> > Well, hold on.. this can't possibly work now :(
>> >
>> > This is what happens when Luis and I disagree ...
>> >
>> > I thought the bandwidth in a given section means the bandwidth that can
>> > be used from this section,
>>
>> No, indeed that was the objective.
>
> That's not what's implemented though.
>
>> > Luis implemented it to mean that a channel
>> > overlapping any part of that section can only use that much bandwidth.
>>
>> 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.

>> > Note sure which was intended?
>>
>> Technically speaking the math should be possible to figure out to
>> enable HT40 or not based on peer channels and although that was
>> assumed the user reported it not allowing HT40 due to the peer
>> channels not allowing HT40. I took your patch as an assumption that
>> was not possible.
>
> 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.

  Luis