On 9/28/2012 4:12 PM, Johannes Berg wrote:
On Fri, 2012-09-28 at 12:39 +0200, Johannes Berg wrote:
On Fri, 2012-09-28 at 13:39 +0530, Mahesh Palivela wrote:
On 09/07/2012 05:40 PM, Johannes Berg wrote:
We don't have to do any calculation in kernel though as far as I can
tell? Maybe we do need the channel, but I think in terms of
*specifying*, in particular in the nl80211 and cfg80211 APIs, we should
stick to the standard if we're going to change it now.
struct ieee80211_channel_config {
enum ieee80211_chan_width chan_width;
u16 center_freq1;
u16 center_freq2;
u16 prim_chan_freq;
};
If we stick to standard, all u16 become u8, as their values range is
from 1-200. But these numbers have to be converted to freqKHz in
reg_chan_use_permitted() to find fits in reg rule or not?
Is that ok?
I prefer MHz for center freqs, but offset for the primary channel, and
this is exactly like table 22-22 in the 802.11ac draft, so only the "u16
primary_channel_freq" becomes "u8 primary_channel_offset", not all of
them change, no?
Ohh, wait, it's called frequency in table 22-22 but actually says the
valid range is 1-200 ... wtf? Ok you're right, then it uses the equation
22-99, but ... hmm that's a bit stupid since it needs the (non-constant)
"Channel starting frequency".
Ok so maybe that wasn't such a good idea. How about we just change
prim_chan_freq to prim_chan_offset and leave the other two unchanged?
we need "channel starting frequency" anyways for calculating center
freq. so we can use same constant for computing primary chan freq as
well. why switch to prim_chan_offset?
Sorry.
--
Thanks,
Mahesh
--
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
