On Wed, Aug 22, 2012 at 11:04:42AM +0200, Johannes Berg wrote: > On Wed, 2012-08-22 at 11:01 +0200, Stanislaw Gruszka wrote: > > > > 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. > > Yes, in theory. However, if this was intended to use the actual "center > freq, bandwidth, control channel offset" values, then it would be much > better to first actually define a struct to hold those, use it here, and > give it to drivers etc. Otherwise, drivers would have to take, e.g. > > - channel = 1 (2412 MHz) > - HT40+ > > and calculate > > - center freq = 2422 MHz > - bandwidth = 40 > - control channel offset = 0 > > before being able to call this function. To me, that seems wrong. I see, we could add helper function that will calculate center_freq/bandwidth, but starting from defining new channel structure and accompanying code in nl80211/mac80211 is more reasonable. 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
