Linux wireless drivers development
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Sam Leffler <sleffler@google.com>
Cc: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>,
	linux-wireless <linux-wireless@vger.kernel.org>,
	Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>,
	Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Subject: Re: [PATCHv2 03/18] mac80211: fix various components for the new 5 and 10 MHz widths
Date: Wed, 15 May 2013 20:12:42 +0200	[thread overview]
Message-ID: <1368641562.20897.11.camel@jlt4.sipsolutions.net> (raw)
In-Reply-To: <CA+yqC4a6W6i9TUoEc1Boxe6a5eun_TSjLB0F+w3F2L_Hn+v_gA@mail.gmail.com> (sfid-20130515_191656_282119_D9E15517)

On Wed, 2013-05-15 at 10:16 -0700, Sam Leffler wrote:
> On Wed, May 15, 2013 at 7:18 AM, Simon Wunderlich
> <simon.wunderlich@s2003.tu-chemnitz.de> wrote:
>         This is a collection of minor fixes:
>          * don't allow HT IEs in IBSS for 5/10 MHz
>          * don't allow HT IEs in Mesh for 5/10 MHz
>          * consider 5 and 10 MHz channels when downgrading
>          * don't try HT rates for 5 and 10 MHz channels when selecting
>         rates
> 
> 
> Perhaps I missed a standards discussion but unilaterally disallowing
> HT rates on 5/10 channels breaks existing functionality (e.g. I use
> them on openwrt).  NOHT should be a regulatory constraint just like it
> is for 20 channels.

I don't see how this would break anything, since we wouldn't advertise
HT capabilities (for now). My point was that that the standard doesn't
(currently) define this, so I think it should be a separate second step
for 5/10 MHz channels to see how to do it in a way that wouldn't break
when/if the standard is changed to allow it, etc.

johannes



  parent reply	other threads:[~2013-05-15 18:12 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-15 14:18 [PATCHv2 00/18] Add support for 5 and 10 MHz channels Simon Wunderlich
2013-05-15 14:18 ` [PATCHv2 01/18] nl80211/cfg80211: add 5 and 10 MHz defines and wiphy flag Simon Wunderlich
2013-05-15 14:18 ` [PATCHv2 02/18] nl80211: add half/quarter channel bitrate tables to supported band struct Simon Wunderlich
2013-05-15 14:18 ` [PATCHv2 03/18] mac80211: fix various components for the new 5 and 10 MHz widths Simon Wunderlich
     [not found]   ` <CA+yqC4a6W6i9TUoEc1Boxe6a5eun_TSjLB0F+w3F2L_Hn+v_gA@mail.gmail.com>
2013-05-15 18:12     ` Johannes Berg [this message]
2013-05-15 20:22       ` Simon Wunderlich
2013-05-15 14:18 ` [PATCHv2 04/18] mac80211: fix timing for 5 MHz and 10 MHz channels Simon Wunderlich
2013-05-15 14:18 ` [PATCHv2 05/18] mac80211: round rates to the next multiple of 500kbps Simon Wunderlich
2013-05-15 14:18 ` [PATCHv2 06/18] mac80211: choose bitrate table according to bandwidth Simon Wunderlich
2013-05-15 14:18 ` [PATCHv2 07/18] mac80211: add radiotap flag and handling for 5/10 MHz Simon Wunderlich
2013-05-15 14:18 ` [PATCHv2 08/18] cfg80211/mac80211: use reduced txpower for 5 and 10 MHz Simon Wunderlich
2013-05-15 14:19 ` [PATCHv2 09/18] mac80211: change IBSS channel state to chandef Simon Wunderlich
2013-05-15 14:19 ` [PATCHv2 10/18] nl80211: allow 5 and 10 MHz channels for IBSS Simon Wunderlich
2013-05-15 14:19 ` [PATCHv2 11/18] ath9k: always use SIFS times from OFDM for 5/10 MHz Simon Wunderlich
2013-05-15 14:19 ` [PATCHv2 12/18] ath9k: use chandef instead of channel_type Simon Wunderlich
2013-05-15 14:19 ` [PATCHv2 13/18] ath9k: add and use 5/10 MHz bitrate tables Simon Wunderlich
2013-05-15 14:19 ` [PATCHv2 14/18] ath9k: report 5/10 MHz channels Simon Wunderlich
2013-05-15 14:19 ` [PATCHv2 15/18] ath9k: announce that ath9k supports 5/10 MHz Simon Wunderlich
2013-05-15 14:19 ` [PATCHv2 16/18] ath5k: add and use 5/10 MHz bitrate tables Simon Wunderlich
2013-05-15 14:19 ` [PATCHv2 17/18] ath5k: report 5/10 MHz channels Simon Wunderlich
2013-05-15 14:19 ` [PATCHv2 18/18] ath5k: enable support for 5 MHz and 10 " Simon Wunderlich
2013-05-15 20:24 ` [PATCHv2 00/18] Add support for 5 " Simon Wunderlich
2013-05-15 20:59 ` Adrian Chadd
2013-05-16 11:40   ` Simon Wunderlich
2013-05-16 15:34     ` Adrian Chadd
2013-05-17  9:58       ` Simon Wunderlich
     [not found]         ` <CA+yqC4bY_5Vd=B7nnmjEnDS+gJwD7fFZBkUCKEw0vb0aWucD5Q@mail.gmail.com>
2013-05-17 14:39           ` Johannes Berg
2013-05-17 15:39         ` Adrian Chadd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1368641562.20897.11.camel@jlt4.sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mathias.kretschmer@fokus.fraunhofer.de \
    --cc=simon.wunderlich@s2003.tu-chemnitz.de \
    --cc=siwu@hrz.tu-chemnitz.de \
    --cc=sleffler@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox