On Wed, Aug 22, 2012 at 09:03:28AM +0200, Johannes Berg wrote: > On Tue, 2012-08-21 at 23:37 +0530, Mahesh Palivela wrote: > > 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. [snip] > > > 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. For starters (for regulatory purpose only) would be sufficient to implement regulatory_chan_use_permitted(center freq, bandwidth, whatever else), and use it where currently IEEE80211_CHAN_NO_HT_X flags are used. Stanislaw -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
