linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: "Richard Schütz" <rschuetz@uni-koblenz.de>,
	linux-wireless@vger.kernel.org
Cc: Simon Wunderlich <sw@simonwunderlich.de>
Subject: Re: [PATCH 2/2] wireless: return correct mandatory rates
Date: Fri, 08 Sep 2017 11:03:33 +0200	[thread overview]
Message-ID: <1504861413.6177.16.camel@sipsolutions.net> (raw)
In-Reply-To: <5aed0ea0-f127-bd1e-ca06-db7edbf56680@uni-koblenz.de>

On Fri, 2017-09-08 at 10:43 +0200, Richard Schütz wrote:
> Am 08.09.2017 um 08:55 schrieb Johannes Berg:
> > On Thu, 2017-09-07 at 17:47 +0200, Richard Schütz wrote:
> > > Use IEEE80211_RATE_MANDATORY_G instead of
> > > IEEE80211_RATE_MANDATORY_B
> > > for comparison to get all mandatory rates in 2.4 GHz band. It is
> > > safe
> > > to do so because ERP mandatory rates are a superset of HR/DSSS
> > > mandatory rates.
> > 
> > This I don't understand - what "comparison" are you talking about?
> 
> Sorry, I meant the condition that checks for the presence of 
> mandatory_flag at the bottom of the function.

Ah, sorry, I got confused with the other patch.

> Do we actually allow 10 MHz and 5 MHz operation in the 2.4 GHz band?
> As  far as I can tell that has only been specified for OFDM PHYs,
> which use the 5 GHz band and are covered by
> IEEE80211_RATE_MANDATORY_A, but I am not a hundred per cent sure
> about that. Cc'ing Simon Wunderlich who originally implemented
> checking of scan_width here.

Clearly we do allow that, since the existing check is:

        if (sband->band == NL80211_BAND_2GHZ) {
                if (scan_width == NL80211_BSS_CHAN_WIDTH_5 ||
                    scan_width == NL80211_BSS_CHAN_WIDTH_10)
                        mandatory_flag = IEEE80211_RATE_MANDATORY_G;

That wouldn't make any sense if we didn't have 5/10 MHz on 2.4 GHz.

> The main intention of this patch series is to fix mandatory rates 
> returned for normal operation in 2.4 GHz band. Currently only 1 Mb/s
> is returned here, which is wrong for both HR/DSSS and ERP PHYs.

The patch is still wrong wrt. 5/10 MHz though.

I think what you really wanted to do is the following:

 * rename RATE_MANDATORY_B to RATE_MANDATORY_HR_DSSS
 * combine RATE_MANDATORY_G/_A to RATE_MANDATORY_OFDM

Then, what you need to do, is change the checks in
ieee80211_mandatory_rates() to be

        if (sband->band == NL80211_BAND_2GHZ) {
                if (scan_width == NL80211_BSS_CHAN_WIDTH_5 ||
                    scan_width == NL80211_BSS_CHAN_WIDTH_10)
                        mandatory_flag = IEEE80211_RATE_MANDATORY_OFDM;
                else
                        mandatory_flag = IEEE80211_RATE_MANDATORY_HR_DSSS;
        } else {
                mandatory_flag = IEEE80211_RATE_MANDATORY_OFDM;
        }

That would actually fix a bug in a way because right now the code
treats HR/DSSS rates (1, 2, 5.5, 11) for 2.4 GHz narrow-band operation
as mandatory, which seems wrong.

johannes

  parent reply	other threads:[~2017-09-08  9:03 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-07 15:47 [PATCH 1/2] wireless: set correct mandatory rate flags Richard Schütz
2017-09-07 15:47 ` [PATCH 2/2] wireless: return correct mandatory rates Richard Schütz
2017-09-08  6:55   ` Johannes Berg
2017-09-08  8:43     ` Richard Schütz
2017-09-08  8:53       ` Richard Schütz
2017-09-08  9:33         ` Simon Wunderlich
2017-09-08  9:03       ` Johannes Berg [this message]
2017-09-08 10:10         ` Richard Schütz
2017-09-08 10:12           ` Johannes Berg
2017-09-08 16:07   ` [PATCH v2 " Richard Schütz
2017-09-21 13:52     ` Johannes Berg
2017-09-22 10:09       ` Richard Schütz
2017-09-22 10:28         ` Johannes Berg
2017-09-08  6:54 ` [PATCH 1/2] wireless: set correct mandatory rate flags Johannes Berg
2017-09-08  8:43   ` Richard Schütz
2017-09-08  8:57     ` Johannes Berg
2017-09-21 13:49 ` Johannes Berg
2018-01-26 22:17 ` Matthias Schiffer
2018-01-30  7:43   ` Johannes Berg
2018-01-30 10:47     ` Matthias Schiffer

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=1504861413.6177.16.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=rschuetz@uni-koblenz.de \
    --cc=sw@simonwunderlich.de \
    /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;
as well as URLs for NNTP newsgroup(s).