[RFC] cfg80211: 80Mhz Bandwidth channel flags in 5Gig band

[RFC] cfg80211: 80Mhz Bandwidth channel flags in 5Gig band

[Mahesh]

This change is for marking 80Mhz bandwidth supported channel flags in 
5Gig band.

Signed-off-by: Mahesh Palivela (maheshp@posedge.com)
---

  include/net/cfg80211.h |   20 +++++++++----
  net/wireless/reg.c     |   72 
++++++++++++++++++++++++++++++++++++++++++++++++
  2 files changed, 86 insertions(+), 6 deletions(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index e0c9ff3..7fb77d5 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -93,18 +93,26 @@ enum ieee80211_band {
   * 	is not permitted.
   * @IEEE80211_CHAN_NO_HT40MINUS: extension channel below this channel
   * 	is not permitted.
+ * @IEEE80211_CHAN_NO_VHT80PLUS: extension channel above this channel
+ * 	is not permitted.
+ * @IEEE80211_CHAN_NO_VHT80MINUS: extension channel below this channel
+ * 	is not permitted.
   */
  enum ieee80211_channel_flags {
-	IEEE80211_CHAN_DISABLED		= 1<<0,
-	IEEE80211_CHAN_PASSIVE_SCAN	= 1<<1,
-	IEEE80211_CHAN_NO_IBSS		= 1<<2,
-	IEEE80211_CHAN_RADAR		= 1<<3,
-	IEEE80211_CHAN_NO_HT40PLUS	= 1<<4,
-	IEEE80211_CHAN_NO_HT40MINUS	= 1<<5,
+	IEEE80211_CHAN_DISABLED		    = 1<<0,
+	IEEE80211_CHAN_PASSIVE_SCAN	    = 1<<1,
+	IEEE80211_CHAN_NO_IBSS		    = 1<<2,
+	IEEE80211_CHAN_RADAR		    = 1<<3,
+	IEEE80211_CHAN_NO_HT40PLUS	    = 1<<4,
+	IEEE80211_CHAN_NO_HT40MINUS	    = 1<<5,
+    IEEE80211_CHAN_NO_VHT80PLUS     = 1<<6,
+    IEEE80211_CHAN_NO_VHT80MINUS    = 1<<7,
  };

  #define IEEE80211_CHAN_NO_HT40 \
  	(IEEE80211_CHAN_NO_HT40PLUS | IEEE80211_CHAN_NO_HT40MINUS)
+#define IEEE80211_CHAN_NO_VHT80 \
+    (IEEE80211_CHAN_NO_VHT80PLUS | IEEE80211_CHAN_NO_VHT80MINUS)

  /**
   * struct ieee80211_channel - channel definition
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index e9a0ac8..dfa8f5d 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1048,6 +1048,77 @@ static void reg_process_beacons(struct wiphy 
*wiphy)
  	wiphy_update_beacon_reg(wiphy);
  }

+static bool is_vht80_not_allowed(struct ieee80211_channel *chan)
+{
+	if (!chan)
+		return true;
+	if (chan->flags & IEEE80211_CHAN_DISABLED)
+		return true;
+	/* This would happen when regulatory rules disallow VHT80 completely 
*/
+	if (IEEE80211_CHAN_NO_VHT80 == (chan->flags & 
(IEEE80211_CHAN_NO_VHT80)))
+		return true;
+	return false;
+}
+
+static void reg_process_vht_flags_channel(struct wiphy *wiphy,
+					 unsigned int chan_idx)
+{
+	struct ieee80211_supported_band *sband;
+	struct ieee80211_channel *channel;
+	struct ieee80211_channel *channel_before = NULL, *channel_after = 
NULL;
+	unsigned int i;
+
+	assert_cfg80211_lock();
+
+	sband = wiphy->bands[IEEE80211_BAND_5GHZ];
+	BUG_ON(chan_idx >= sband->n_channels);
+	channel = &sband->channels[chan_idx];
+
+	if (is_vht80_not_allowed(channel)) {
+		channel->flags |= IEEE80211_CHAN_NO_VHT80;
+		return;
+	}
+
+	/*
+	 * We need to ensure the extension channels exist to
+	 * be able to use VHT80- or VHT80+, this finds them (or not)
+	 */
+	for (i = 0; i < sband->n_channels; i++) {
+		struct ieee80211_channel *c = &sband->channels[i];
+		if (c->center_freq == (channel->center_freq - 40))
+			channel_before = c;
+		if (c->center_freq == (channel->center_freq + 40))
+			channel_after = c;
+	}
+
+	/*
+	 * Please note that this assumes target bandwidth is 40 MHz,
+	 * if that ever changes we also need to change the below logic
+	 * to include that as well.
+	 */
+	if (is_vht80_not_allowed(channel_before))
+		channel->flags |= IEEE80211_CHAN_NO_VHT80MINUS;
+	else
+		channel->flags &= ~IEEE80211_CHAN_NO_VHT80MINUS;
+
+	if (is_vht80_not_allowed(channel_after))
+		channel->flags |= IEEE80211_CHAN_NO_VHT80PLUS;
+	else
+		channel->flags &= ~IEEE80211_CHAN_NO_VHT80PLUS;
+}
+
+static void reg_process_vht_flags(struct wiphy *wiphy)
+{
+	unsigned int i;
+	struct ieee80211_supported_band *sband;
+
+	BUG_ON(!wiphy->bands[IEEE80211_BAND_5GHZ]);
+	sband = wiphy->bands[IEEE80211_BAND_5GHZ];
+
+	for (i = 0; i < sband->n_channels; i++)
+		reg_process_vht_flags_channel(wiphy, i);
+}
+
  static bool is_ht40_not_allowed(struct ieee80211_channel *chan)
  {
  	if (!chan)
@@ -1154,6 +1225,7 @@ static void wiphy_update_regulatory(struct wiphy 
*wiphy,

  	reg_process_beacons(wiphy);
  	reg_process_ht_flags(wiphy);
+	reg_process_vht_flags(wiphy);
  	if (wiphy->reg_notifier)
  		wiphy->reg_notifier(wiphy, last_request);
  }

Re: [RFC] cfg80211: 80Mhz Bandwidth channel flags in 5Gig band

[Johannes Berg]

On Wed, 2012-02-22 at 23:21 +0530, Mahesh wrote:
> This change is for marking 80Mhz bandwidth supported channel flags in 
> 5Gig band.

This patch is not only completely mangled, it also neglects to actually
support this in the regdb etc. What's the point?

johannes


> Signed-off-by: Mahesh Palivela (maheshp@posedge.com)
> ---
> 
>   include/net/cfg80211.h |   20 +++++++++----
>   net/wireless/reg.c     |   72 
> ++++++++++++++++++++++++++++++++++++++++++++++++
>   2 files changed, 86 insertions(+), 6 deletions(-)
> 
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index e0c9ff3..7fb77d5 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -93,18 +93,26 @@ enum ieee80211_band {
>    * 	is not permitted.
>    * @IEEE80211_CHAN_NO_HT40MINUS: extension channel below this channel
>    * 	is not permitted.
> + * @IEEE80211_CHAN_NO_VHT80PLUS: extension channel above this channel
> + * 	is not permitted.
> + * @IEEE80211_CHAN_NO_VHT80MINUS: extension channel below this channel
> + * 	is not permitted.
>    */
>   enum ieee80211_channel_flags {
> -	IEEE80211_CHAN_DISABLED		= 1<<0,
> -	IEEE80211_CHAN_PASSIVE_SCAN	= 1<<1,
> -	IEEE80211_CHAN_NO_IBSS		= 1<<2,
> -	IEEE80211_CHAN_RADAR		= 1<<3,
> -	IEEE80211_CHAN_NO_HT40PLUS	= 1<<4,
> -	IEEE80211_CHAN_NO_HT40MINUS	= 1<<5,
> +	IEEE80211_CHAN_DISABLED		    = 1<<0,
> +	IEEE80211_CHAN_PASSIVE_SCAN	    = 1<<1,
> +	IEEE80211_CHAN_NO_IBSS		    = 1<<2,
> +	IEEE80211_CHAN_RADAR		    = 1<<3,
> +	IEEE80211_CHAN_NO_HT40PLUS	    = 1<<4,
> +	IEEE80211_CHAN_NO_HT40MINUS	    = 1<<5,
> +    IEEE80211_CHAN_NO_VHT80PLUS     = 1<<6,
> +    IEEE80211_CHAN_NO_VHT80MINUS    = 1<<7,
>   };
> 
>   #define IEEE80211_CHAN_NO_HT40 \
>   	(IEEE80211_CHAN_NO_HT40PLUS | IEEE80211_CHAN_NO_HT40MINUS)
> +#define IEEE80211_CHAN_NO_VHT80 \
> +    (IEEE80211_CHAN_NO_VHT80PLUS | IEEE80211_CHAN_NO_VHT80MINUS)
> 
>   /**
>    * struct ieee80211_channel - channel definition
> diff --git a/net/wireless/reg.c b/net/wireless/reg.c
> index e9a0ac8..dfa8f5d 100644
> --- a/net/wireless/reg.c
> +++ b/net/wireless/reg.c
> @@ -1048,6 +1048,77 @@ static void reg_process_beacons(struct wiphy 
> *wiphy)
>   	wiphy_update_beacon_reg(wiphy);
>   }
> 
> +static bool is_vht80_not_allowed(struct ieee80211_channel *chan)
> +{
> +	if (!chan)
> +		return true;
> +	if (chan->flags & IEEE80211_CHAN_DISABLED)
> +		return true;
> +	/* This would happen when regulatory rules disallow VHT80 completely 
> */
> +	if (IEEE80211_CHAN_NO_VHT80 == (chan->flags & 
> (IEEE80211_CHAN_NO_VHT80)))
> +		return true;
> +	return false;
> +}
> +
> +static void reg_process_vht_flags_channel(struct wiphy *wiphy,
> +					 unsigned int chan_idx)
> +{
> +	struct ieee80211_supported_band *sband;
> +	struct ieee80211_channel *channel;
> +	struct ieee80211_channel *channel_before = NULL, *channel_after = 
> NULL;
> +	unsigned int i;
> +
> +	assert_cfg80211_lock();
> +
> +	sband = wiphy->bands[IEEE80211_BAND_5GHZ];
> +	BUG_ON(chan_idx >= sband->n_channels);
> +	channel = &sband->channels[chan_idx];
> +
> +	if (is_vht80_not_allowed(channel)) {
> +		channel->flags |= IEEE80211_CHAN_NO_VHT80;
> +		return;
> +	}
> +
> +	/*
> +	 * We need to ensure the extension channels exist to
> +	 * be able to use VHT80- or VHT80+, this finds them (or not)
> +	 */
> +	for (i = 0; i < sband->n_channels; i++) {
> +		struct ieee80211_channel *c = &sband->channels[i];
> +		if (c->center_freq == (channel->center_freq - 40))
> +			channel_before = c;
> +		if (c->center_freq == (channel->center_freq + 40))
> +			channel_after = c;
> +	}
> +
> +	/*
> +	 * Please note that this assumes target bandwidth is 40 MHz,
> +	 * if that ever changes we also need to change the below logic
> +	 * to include that as well.
> +	 */
> +	if (is_vht80_not_allowed(channel_before))
> +		channel->flags |= IEEE80211_CHAN_NO_VHT80MINUS;
> +	else
> +		channel->flags &= ~IEEE80211_CHAN_NO_VHT80MINUS;
> +
> +	if (is_vht80_not_allowed(channel_after))
> +		channel->flags |= IEEE80211_CHAN_NO_VHT80PLUS;
> +	else
> +		channel->flags &= ~IEEE80211_CHAN_NO_VHT80PLUS;
> +}
> +
> +static void reg_process_vht_flags(struct wiphy *wiphy)
> +{
> +	unsigned int i;
> +	struct ieee80211_supported_band *sband;
> +
> +	BUG_ON(!wiphy->bands[IEEE80211_BAND_5GHZ]);
> +	sband = wiphy->bands[IEEE80211_BAND_5GHZ];
> +
> +	for (i = 0; i < sband->n_channels; i++)
> +		reg_process_vht_flags_channel(wiphy, i);
> +}
> +
>   static bool is_ht40_not_allowed(struct ieee80211_channel *chan)
>   {
>   	if (!chan)
> @@ -1154,6 +1225,7 @@ static void wiphy_update_regulatory(struct wiphy 
> *wiphy,
> 
>   	reg_process_beacons(wiphy);
>   	reg_process_ht_flags(wiphy);
> +	reg_process_vht_flags(wiphy);
>   	if (wiphy->reg_notifier)
>   		wiphy->reg_notifier(wiphy, last_request);
>   }
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [RFC] cfg80211: 80Mhz Bandwidth channel flags in 5Gig band

[Johannes Berg]

On Wed, 2012-02-22 at 18:57 +0100, Johannes Berg wrote:
> On Wed, 2012-02-22 at 23:21 +0530, Mahesh wrote:
> > This change is for marking 80Mhz bandwidth supported channel flags in 
> > 5Gig band.
> 
> This patch is not only completely mangled, it also neglects to actually
> support this in the regdb etc. What's the point?

I should elaborate. Something like this code is needed, but right now
the regulatory database contains things like

        (5150 - 5350 @ 40), (N/A, 100 mW), NO-OUTDOOR, DFS

which means at most 40 MHz can be used.

In your patch, you don't even check this maximum bandwidth, which is a
bug, but even if you did the database would have to be changed.

Also, we probably really need to introduce handling of spectral power
limits to make this worthwhile?

johannes

Re: [RFCv2] cfg80211: 80Mhz Bandwidth channel flags in 5Gig band

[Mahesh]

On 02/23/2012 12:27 AM, Johannes Berg wrote:
> On Wed, 2012-02-22 at 18:57 +0100, Johannes Berg wrote:
>> On Wed, 2012-02-22 at 23:21 +0530, Mahesh wrote:
>>> This change is for marking 80Mhz bandwidth supported channel flags in
>>> 5Gig band.
>>
>> This patch is not only completely mangled, it also neglects to actually
>> support this in the regdb etc. What's the point?
>
> I should elaborate. Something like this code is needed, but right now
> the regulatory database contains things like
>
>          (5150 - 5350 @ 40), (N/A, 100 mW), NO-OUTDOOR, DFS
>
> which means at most 40 MHz can be used.
>
> In your patch, you don't even check this maximum bandwidth, which is a
> bug, but even if you did the database would have to be changed.
>
> Also, we probably really need to introduce handling of spectral power
> limits to make this worthwhile?
>
> johannes
>

Agree. we will work towards updating regulatory database with 80Mhz 
bandwidth in 5Gig band. I had modified code to check maximum bandwidth 
as well. Please find the updated change below.

Signed-of-by: Mahesh Palivela (maheshp@posedge.com)
---

  include/net/cfg80211.h |   20 ++++++++---
  net/wireless/reg.c     |   87 
+++++++++++++++++++++++++++++++++++++++++++++--
  2 files changed, 97 insertions(+), 10 deletions(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 755a770..ddc0524 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -93,18 +93,26 @@ enum ieee80211_band {
   * 	is not permitted.
   * @IEEE80211_CHAN_NO_HT40MINUS: extension channel below this channel
   * 	is not permitted.
+ * @IEEE80211_CHAN_NO_VHT80PLUS: extension channel above this channel
+ * 	is not permitted.
+ * @IEEE80211_CHAN_NO_VHT80MINUS: extension channel below this channel
+ * 	is not permitted.
   */
  enum ieee80211_channel_flags {
-	IEEE80211_CHAN_DISABLED		= 1<<0,
-	IEEE80211_CHAN_PASSIVE_SCAN	= 1<<1,
-	IEEE80211_CHAN_NO_IBSS		= 1<<2,
-	IEEE80211_CHAN_RADAR		= 1<<3,
-	IEEE80211_CHAN_NO_HT40PLUS	= 1<<4,
-	IEEE80211_CHAN_NO_HT40MINUS	= 1<<5,
+	IEEE80211_CHAN_DISABLED		    = 1<<0,
+	IEEE80211_CHAN_PASSIVE_SCAN	    = 1<<1,
+	IEEE80211_CHAN_NO_IBSS		    = 1<<2,
+	IEEE80211_CHAN_RADAR		    = 1<<3,
+	IEEE80211_CHAN_NO_HT40PLUS	    = 1<<4,
+	IEEE80211_CHAN_NO_HT40MINUS	    = 1<<5,
+	IEEE80211_CHAN_NO_VHT80PLUS	    = 1<<6,
+	IEEE80211_CHAN_NO_VHT80MINUS	= 1<<7,
  };

  #define IEEE80211_CHAN_NO_HT40 \
  	(IEEE80211_CHAN_NO_HT40PLUS | IEEE80211_CHAN_NO_HT40MINUS)
+#define IEEE80211_CHAN_NO_VHT80 \
+	(IEEE80211_CHAN_NO_VHT80PLUS | IEEE80211_CHAN_NO_VHT80MINUS)

  /**
   * struct ieee80211_channel - channel definition
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index e9a0ac8..c0c905e 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -858,8 +858,11 @@ static void handle_channel(struct wiphy *wiphy,
  	power_rule = &reg_rule->power_rule;
  	freq_range = &reg_rule->freq_range;

-	if (freq_range->max_bandwidth_khz < MHZ_TO_KHZ(40))
-		bw_flags = IEEE80211_CHAN_NO_HT40;
+	if (freq_range->max_bandwidth_khz < MHZ_TO_KHZ(40)) {
+		bw_flags = IEEE80211_CHAN_NO_HT40 | IEEE80211_CHAN_NO_VHT80;
+    } else if (freq_range->max_bandwidth_khz < MHZ_TO_KHZ(80)) {
+		bw_flags = IEEE80211_CHAN_NO_VHT80;
+    }

  	if (last_request->initiator == NL80211_REGDOM_SET_BY_DRIVER &&
  	    request_wiphy && request_wiphy == wiphy &&
@@ -1048,6 +1051,77 @@ static void reg_process_beacons(struct wiphy *wiphy)
  	wiphy_update_beacon_reg(wiphy);
  }

+static bool is_vht80_not_allowed(struct ieee80211_channel *chan)
+{
+	if (!chan)
+		return true;
+	if (chan->flags & IEEE80211_CHAN_DISABLED)
+		return true;
+	/* This would happen when regulatory rules disallow VHT80 completely */
+	if (IEEE80211_CHAN_NO_VHT80 == (chan->flags & (IEEE80211_CHAN_NO_VHT80)))
+		return true;
+	return false;
+}
+
+static void reg_process_vht_flags_channel(struct wiphy *wiphy,
+					 unsigned int chan_idx)
+{
+	struct ieee80211_supported_band *sband;
+	struct ieee80211_channel *channel;
+	struct ieee80211_channel *channel_before = NULL, *channel_after = NULL;
+	unsigned int i;
+
+	assert_cfg80211_lock();
+
+	sband = wiphy->bands[IEEE80211_BAND_5GHZ];
+	BUG_ON(chan_idx >= sband->n_channels);
+	channel = &sband->channels[chan_idx];
+
+	if (is_vht80_not_allowed(channel)) {
+		channel->flags |= IEEE80211_CHAN_NO_VHT80;
+		return;
+	}
+
+	/*
+	 * We need to ensure the extension channels exist to
+	 * be able to use VHT80- or VHT80+, this finds them (or not)
+	 */
+	for (i = 0; i < sband->n_channels; i++) {
+		struct ieee80211_channel *c = &sband->channels[i];
+		if (c->center_freq == (channel->center_freq - 40))
+			channel_before = c;
+		if (c->center_freq == (channel->center_freq + 40))
+			channel_after = c;
+	}
+
+	/*
+	 * Please note that this assumes target bandwidth is 40 MHz,
+	 * if that ever changes we also need to change the below logic
+	 * to include that as well.
+	 */
+	if (is_vht80_not_allowed(channel_before))
+		channel->flags |= IEEE80211_CHAN_NO_VHT80MINUS;
+	else
+		channel->flags &= ~IEEE80211_CHAN_NO_VHT80MINUS;
+
+	if (is_vht80_not_allowed(channel_after))
+		channel->flags |= IEEE80211_CHAN_NO_VHT80PLUS;
+	else
+		channel->flags &= ~IEEE80211_CHAN_NO_VHT80PLUS;
+}
+
+static void reg_process_vht_flags(struct wiphy *wiphy)
+{
+	unsigned int i;
+	struct ieee80211_supported_band *sband;
+
+	BUG_ON(!wiphy->bands[IEEE80211_BAND_5GHZ]);
+	sband = wiphy->bands[IEEE80211_BAND_5GHZ];
+
+	for (i = 0; i < sband->n_channels; i++)
+		reg_process_vht_flags_channel(wiphy, i);
+}
+
  static bool is_ht40_not_allowed(struct ieee80211_channel *chan)
  {
  	if (!chan)
@@ -1154,6 +1228,8 @@ static void wiphy_update_regulatory(struct wiphy 
*wiphy,

  	reg_process_beacons(wiphy);
  	reg_process_ht_flags(wiphy);
+	reg_process_vht_flags(wiphy);
+
  	if (wiphy->reg_notifier)
  		wiphy->reg_notifier(wiphy, last_request);
  }
@@ -1227,8 +1303,11 @@ static void handle_channel_custom(struct wiphy 
*wiphy,
  	power_rule = &reg_rule->power_rule;
  	freq_range = &reg_rule->freq_range;

-	if (freq_range->max_bandwidth_khz < MHZ_TO_KHZ(40))
-		bw_flags = IEEE80211_CHAN_NO_HT40;
+	if (freq_range->max_bandwidth_khz < MHZ_TO_KHZ(40)) {
+		bw_flags = IEEE80211_CHAN_NO_HT40 | IEEE80211_CHAN_NO_VHT80;
+    } else if (freq_range->max_bandwidth_khz < MHZ_TO_KHZ(80)) {
+		bw_flags = IEEE80211_CHAN_NO_VHT80;
+    }

  	chan->flags |= map_regdom_flags(reg_rule->flags) | bw_flags;
  	chan->max_antenna_gain = (int) MBI_TO_DBI(power_rule->max_antenna_gain);

Re: [RFCv2] cfg80211: 80Mhz Bandwidth channel flags in 5Gig band

[Adrian Chadd]

Hi,

Since what your _actual_ commit is doing is "begin fleshing out
802.11ac support", I suggest someone spark a discussion or two about
it first..


adrian

Re: [RFCv2] cfg80211: 80Mhz Bandwidth channel flags in 5Gig band

[Mahesh]

Sure Adrian. we can participate in discussion.


Thanks,
Mahesh

On 02/24/2012 11:13 AM, Adrian Chadd wrote:
> Hi,
>
> Since what your _actual_ commit is doing is "begin fleshing out
> 802.11ac support", I suggest someone spark a discussion or two about
> it first..
>
>
> adrian

Re: [RFCv2] cfg80211: 80Mhz Bandwidth channel flags in 5Gig band

[Johannes Berg]

On Thu, 2012-02-23 at 21:43 -0800, Adrian Chadd wrote:
> Hi,
> 
> Since what your _actual_ commit is doing is "begin fleshing out
> 802.11ac support", I suggest someone spark a discussion or two about
> it first..

Now you did ;-)

I think the regulatory stuff is important, but obviously we also need
VHT advertising, all the mac80211 (and hostapd) bits to add the IEs in
the right places, station capability stuff. Some extensions for bitrate
information/rate control will be needed -- maybe we should get started
on radiotap VHT extensions also.

Then stuff like CSA with wide bandwidth channel switch, VHT transmit
power envelope, extended power constraint & quiet channel handling.

If anyone wants beamforming, I'm not sure where that needs to be
implemented, and MU-MIMO will be interesting as well.

I also suspect A-MSDU will become more interesting, and I don't even
want to think about VHT-IBSS.

johannes

Re: [RFCv2] cfg80211: 80Mhz Bandwidth channel flags in 5Gig band

[Johannes Berg]

On Fri, 2012-02-24 at 10:55 +0530, Mahesh wrote:

> Agree. we will work towards updating regulatory database with 80Mhz 
> bandwidth in 5Gig band. I had modified code to check maximum bandwidth 
> as well. Please find the updated change below.

> -	if (freq_range->max_bandwidth_khz < MHZ_TO_KHZ(40))
> -		bw_flags = IEEE80211_CHAN_NO_HT40;
> +	if (freq_range->max_bandwidth_khz < MHZ_TO_KHZ(40)) {
> +		bw_flags = IEEE80211_CHAN_NO_HT40 | IEEE80211_CHAN_NO_VHT80;
> +    } else if (freq_range->max_bandwidth_khz < MHZ_TO_KHZ(80)) {
> +		bw_flags = IEEE80211_CHAN_NO_VHT80;
> +    }

no braces needed

Also this will always be true now, so the patch isn't very useful right
now?


> -	if (freq_range->max_bandwidth_khz < MHZ_TO_KHZ(40))
> -		bw_flags = IEEE80211_CHAN_NO_HT40;
> +	if (freq_range->max_bandwidth_khz < MHZ_TO_KHZ(40)) {
> +		bw_flags = IEEE80211_CHAN_NO_HT40 | IEEE80211_CHAN_NO_VHT80;
> +    } else if (freq_range->max_bandwidth_khz < MHZ_TO_KHZ(80)) {
> +		bw_flags = IEEE80211_CHAN_NO_VHT80;
> +    }

Seems some refactoring could be useful since this is duplicated?

johannes

Re: [RFCv2] cfg80211: 80Mhz Bandwidth channel flags in 5Gig band

[Mahesh]

On 02/24/2012 01:25 PM, Johannes Berg wrote:
> On Fri, 2012-02-24 at 10:55 +0530, Mahesh wrote:
>
>> Agree. we will work towards updating regulatory database with 80Mhz
>> bandwidth in 5Gig band. I had modified code to check maximum bandwidth
>> as well. Please find the updated change below.
>
>> -	if (freq_range->max_bandwidth_khz<  MHZ_TO_KHZ(40))
>> -		bw_flags = IEEE80211_CHAN_NO_HT40;
>> +	if (freq_range->max_bandwidth_khz<  MHZ_TO_KHZ(40)) {
>> +		bw_flags = IEEE80211_CHAN_NO_HT40 | IEEE80211_CHAN_NO_VHT80;
>> +    } else if (freq_range->max_bandwidth_khz<  MHZ_TO_KHZ(80)) {
>> +		bw_flags = IEEE80211_CHAN_NO_VHT80;
>> +    }
>
> no braces needed
>
> Also this will always be true now, so the patch isn't very useful right
> now?
True. But once reg database reflects 80MHz BW, we need it. Anyways its 
part of new feature. Not a bug fix.
>
>
>> -	if (freq_range->max_bandwidth_khz<  MHZ_TO_KHZ(40))
>> -		bw_flags = IEEE80211_CHAN_NO_HT40;
>> +	if (freq_range->max_bandwidth_khz<  MHZ_TO_KHZ(40)) {
>> +		bw_flags = IEEE80211_CHAN_NO_HT40 | IEEE80211_CHAN_NO_VHT80;
>> +    } else if (freq_range->max_bandwidth_khz<  MHZ_TO_KHZ(80)) {
>> +		bw_flags = IEEE80211_CHAN_NO_VHT80;
>> +    }
>
> Seems some refactoring could be useful since this is duplicated?
May be a macro?

>
> johannes
>

Re: [RFCv2] cfg80211: 80Mhz Bandwidth channel flags in 5Gig band

[Adrian Chadd]

.. and this doesn't yet address VHT160, which is part of the 11ac spec too.

I think it's worth having a bit more of a total, overall architecture
discussion about what 11ac support -should- look like before bits are
comitted, so you don't have to go and change them later (and possibly
break some internal company drivers whilst doing so.)

So - what else is likely needed for the upcoming 11ac standard?

Disclaimer: I'm speaking from my personal opinion rather than that of
Qualcomm Atheros.



adrian

Re: [RFCv2] cfg80211: 80Mhz Bandwidth channel flags in 5Gig band

[Johannes Berg]

On Sat, 2012-02-25 at 11:22 -0800, Adrian Chadd wrote:
> .. and this doesn't yet address VHT160, which is part of the 11ac spec too.
> 
> I think it's worth having a bit more of a total, overall architecture
> discussion about what 11ac support -should- look like before bits are
> comitted, so you don't have to go and change them later (and possibly
> break some internal company drivers whilst doing so.)

Not like I care about that at all ... we change things all the time and
break drivers in the process. Is it even feasible to have non-upstream
drivers on the current wireless stack? I'd think you'd have to dedicate
one person full time to following our mac80211 changes ;-)

> So - what else is likely needed for the upcoming 11ac standard?

Well so obviously we need things like VHT capability stuff (advertising,
in scans, in assoc, for AP/GO mode in station info). I suspect you're
talking only about the regulatory/channel stuff? Mostly I'm confused
about the split channel thing there but I suppose regulatory-wise it's
just like using two channels at the same time.

> Disclaimer: I'm speaking from my personal opinion rather than that of
> Qualcomm Atheros.

Does anyone here have an "official opinion"? I doubt it :)

johannes

Re: 802.11ac support

[Johannes Berg]

On Mon, 2012-04-02 at 14:07 +0530, Mahesh wrote:

> I had analysed mac80211 code to see what changes are required for 11ac 
> support. Attached word doc describes mac80211 modules in detail and last 
> section describing what changes we need for 11ac. This is a proposal.
> Please review and let me know your opinion.

You really shouldn't try to send word documents to the list, they won't
arrive anyway. Also, it's bad form to send out documents that say
"confidential" all over them ...
Most people also probably don't care about your analysis of what
mac80211 already does.

In any case, here's my list of things I think will/may need to be done
for 11ac in the stack:
 * extend regulatory framework (cfg80211)
 * advertise VHT capabilities (nl80211/cfg80211/mac80211 & each driver)
 * advertise VHT in scan (mac80211)
 * advertise VHT in assoc req (mac80211)
 * advertise VHT in P2P probe responses (wpa_supplicant)
 * advertise VHT in AP/GO mode beacons/probe responses
   (wpa_supplicant/hostapd)
 * handle per-station VHT capa (mac80211, wpa_s)
 * extended CSA (mac80211)
 * VHT transmit power envelope/extended power constraint (mac80211)
 * quiet channels?
 * HT/VHT basic rate handling?
 * neighbor reports?
 * beamforming action frame support? (mac80211)

johannes

Re: 802.11ac support

[Johannes Berg]

On Tue, 2012-04-03 at 14:06 +0200, Johannes Berg wrote:

> In any case, here's my list of things I think will/may need to be done
> for 11ac in the stack:
[...]

It'd also be nice to have iw parse the VHT IEs properly, completely
forgot about that (but it's really easy)

johannes

Re: 802.11ac support

[Mahesh]

On 04/03/2012 05:36 PM, Johannes Berg wrote:
> On Mon, 2012-04-02 at 14:07 +0530, Mahesh wrote:
>
>> I had analysed mac80211 code to see what changes are required for 11ac
>> support. Attached word doc describes mac80211 modules in detail and last
>> section describing what changes we need for 11ac. This is a proposal.
>> Please review and let me know your opinion.
> You really shouldn't try to send word documents to the list, they won't
> arrive anyway. Also, it's bad form to send out documents that say
> "confidential" all over them ...
> Most people also probably don't care about your analysis of what
> mac80211 already does.
>
> In any case, here's my list of things I think will/may need to be done
> for 11ac in the stack:
>   * extend regulatory framework (cfg80211)
>   * advertise VHT capabilities (nl80211/cfg80211/mac80211&  each driver)
>   * advertise VHT in scan (mac80211)
>   * advertise VHT in assoc req (mac80211)
>   * advertise VHT in P2P probe responses (wpa_supplicant)
>   * advertise VHT in AP/GO mode beacons/probe responses
>     (wpa_supplicant/hostapd)
>   * handle per-station VHT capa (mac80211, wpa_s)
>   * extended CSA (mac80211)
>   * VHT transmit power envelope/extended power constraint (mac80211)
>   * quiet channels?
>   * HT/VHT basic rate handling?
>   * neighbor reports?
>   * beamforming action frame support? (mac80211)
>
> johannes
>
Thanks for listing the 11ac requirements. will work on those and post my 
updates.

~Mahesh

Re: 802.11ac support

[Johannes Berg]

On Thu, 2012-04-05 at 09:51 +0530, Mahesh wrote:

> > In any case, here's my list of things I think will/may need to be done
> > for 11ac in the stack:
> >   * extend regulatory framework (cfg80211)
> >   * advertise VHT capabilities (nl80211/cfg80211/mac80211&  each driver)
> >   * advertise VHT in scan (mac80211)
> >   * advertise VHT in assoc req (mac80211)
> >   * advertise VHT in P2P probe responses (wpa_supplicant)
> >   * advertise VHT in AP/GO mode beacons/probe responses
> >     (wpa_supplicant/hostapd)
> >   * handle per-station VHT capa (mac80211, wpa_s)
> >   * extended CSA (mac80211)
> >   * VHT transmit power envelope/extended power constraint (mac80211)
> >   * quiet channels?
> >   * HT/VHT basic rate handling?
> >   * neighbor reports?
> >   * beamforming action frame support? (mac80211)

> Thanks for listing the 11ac requirements. will work on those and post my 
> updates.

When you start working on them, I suggest roughly the list in the order
above. Regulatory might not be the first thing though.

If you do though, please don't do everything and then post all patches
at once -- each of those items should be self-contained enough to post
separately. This helps synchronise with others who might be working on
it and also helps since we can review the code and suggest corrections
if needed.

Let me know if you need more info!

Thanks,
johannes