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