2012-03-20 14:40:13

by Michal Kazior

Subject: [RFC 08/12] mac80211: introduce IEEE80211_HW_SUPPORTS_MULTI_CHANNEL

Signed-off-by: Michal Kazior <[email protected]>
---
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.
+ *
* @IEEE80211_HW_SUPPORTS_STATIC_SMPS:
* Hardware supports static spatial multiplexing powersave,
* ie. can turn off all but one chain even on HT connections
@@ -1196,7 +1199,7 @@ enum ieee80211_hw_flags {
IEEE80211_HW_PS_NULLFUNC_STACK = 1<<11,
IEEE80211_HW_SUPPORTS_DYNAMIC_PS = 1<<12,
IEEE80211_HW_MFP_CAPABLE = 1<<13,
- /* reuse bit 14 */
+ IEEE80211_HW_SUPPORTS_MULTI_CHANNEL = 1<<14,
IEEE80211_HW_SUPPORTS_STATIC_SMPS = 1<<15,
IEEE80211_HW_SUPPORTS_DYNAMIC_SMPS = 1<<16,
IEEE80211_HW_SUPPORTS_UAPSD = 1<<17,
--
1.7.0.4

2012-03-23 08:52:07

by Johannes Berg

Subject: Re: [RFC 08/12] mac80211: introduce IEEE80211_HW_SUPPORTS_MULTI_CHANNEL

On Mon, 2012-03-19 at 11:36 +0100, Michal Kazior wrote:
> Signed-off-by: Michal Kazior <[email protected]>
> ---
> 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