Re: [PATCH] cfg80211: VHT (11ac) Regulatory change

[Mahesh Palivela <maheshp@posedge.com>]

On 8/21/2012 9:23 PM, Johannes Berg wrote:
> On Tue, 2012-08-21 at 19:05 +0530, Mahesh Palivela wrote:
>
>> so we are talking about how to specify channel info to cfg/mac80211 from
>> upper layers.
>
> Correct
>
>> But regulatory tells if that channel config is allowed or not.
>
> Correct.
>
>> so derive channel type from center freq, width and control chan offset.
>> Then determine if that channel type is allowed from regulatory flags?
>>
>> In short we have scaled approach on specifying channel info but not
>> regulatory. Please comment.
>
> Well, we don't really have it yet :-)
>
> I think the question really is whether or not we actually need the
> flags. Sometimes, but very rarely really, we need to answer the question
>
>          Is this set of parameters allowed with the current regulatory
>          rules?
>
> There's nothing that says this needs to be a flag. It could just as well
> be a function
>
> bool regulatory_chan_use_permitted(...);
>
> where the ... gives all the necessary parameters or maybe some structure
> holding all these.
>
> If this was a function, it could go back to the regulatory definitions
> (that we hopefully keep track of in the kernel) and actually use the
> algorithm that today we use to determine the flags to determine the
> answer.
>
> Today, with the flags, we basically pre-determine the answers to all
> possible such questions, and encode the answers in the flags for each
> channel. If we don't pre-determine the answers, then we can get away
> without any flags at all.
>
> Does that make sense?
>
Yes it does. Basically we want to retire look up table approach and 
compute everytime as its not scalable. Fine. In that case, even we need 
to cover HT20, HT40-, HT40+ as well right?

> Still doesn't solve the problems we saw with how to configure the
> channel with considerations such as
>    - bandwidth
>    - center frequency
>    - primary subchannel
>    - 80 + 80 (which is basically two such channels?)
>
Yes It does. From center freq, width, control chan offset we know the 
secondary chans. That's all we want. For 80+80 configuration, we will 
get two center freq values.

> johannes
>

-- 
Thanks,
Mahesh