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