On Mon, 2012-03-19 at 11:36 +0100, Michal Kazior wrote:
> Signed-off-by: Michal Kazior <michal.kazior@xxxxxxxxx>
> ---
> include/net/mac80211.h | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/include/net/mac80211.h b/include/net/mac80211.h
> index c114b18..f7f0252 100644
> --- a/include/net/mac80211.h
> +++ b/include/net/mac80211.h
> @@ -1130,6 +1130,9 @@ enum sta_notify_cmd {
> * @IEEE80211_HW_MFP_CAPABLE:
> * Hardware supports management frame protection (MFP, IEEE 802.11w).
> *
> + * @IEEE80211_HW_SUPPORTS_MULTI_CHANNEL
> + * Hardware supports concurrent multi-channel operation.
This isn't nearly as fully-featured as we need, I think.
There is undoubtedly going to be hardware that doesn't support one
channel per virtual interface, simply because it can only do maybe two
or three channels and many more virtual interfaces.
Now, we already have this advertising though in the interface
combinations, so this flag isn't necessary.
The question is how we structure the API, the two possibilities I was
thinking of are:
1) do similar to what you did, have per-interface channel and let the
driver sort it out -- however this still requires channel
compatibility checks in mac80211 etc.
2) keep mac80211 doing more work and introduce API like
* add channel context
* move vif A to channel context X
* etc.
I'm not sure which one's better, and I still have to look at the monitor
interface implementation to make sure we do it right.
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
