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

[Johannes Berg <johannes@sipsolutions.net>]

On Tue, 2012-08-21 at 23:37 +0530, Mahesh Palivela wrote:

> > 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?

I think we should, yeah. Might even just start with that to make the
transition.

> > 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.

Yeah but we don't have that yet. We could do it that way, sure, but it
has wide-spread implications, since we'll need to
 - use this new form of specifying channels all over mac80211 and all
   drivers,
 - define new nl80211 attributes for it,
 - write new code in nl80211 to handle all this,
 - and parse the old attributes into the new data structure(s) so
   drivers use the new API but userspace can continue to use the old

None of that is done yet.

johannes