All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Ben Greear <greearb@candelatech.com>,
	"Pedersen, Thomas" <twp@qca.qualcomm.com>
Cc: linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH] cfg80211: cap 20MHz VHT bitrate at MCS 8
Date: Tue, 04 Oct 2016 11:32:12 +0200	[thread overview]
Message-ID: <1475573532.5324.47.camel@sipsolutions.net> (raw)
In-Reply-To: <57E01026.9030604@candelatech.com>

Sorry - needed some time to think through this thread again.

> I think it is a moot point as far as this change goes:  Regardless of
> whether the NIC should or not, it _does_.  So, mis-reporting it up
> the stack only hides the issue and does not even give the user a clue
> that on-the-air encoding may be slightly off-spec.

Arguably, reporting something that *seems* sane, like this patch does,
will do more to hide it than reporting 0 which is clearly bogus, no?

I realize you were replying to whether or not the *driver* should
"misreport" it, but the same argument applies the other way here, imho.

> If the on-air encoding is an issue, then we need to hack the firmware
> to disable this 'feature', but that is a completely separate issue.

I guess it trusts rate control enough to try, and if it cannot be
received by a spec-abiding receiver, it won't use it due to the
failures ... not such a big deal I guess, even though it's odd.

Does /anyone/ know why the spec disallowed it? Perhaps those "system"
people you refer to?

> Once this patch goes in, someone might consider properly reporting
> CCK rx rates for 5Ghz band too:  ath10k can do this 'feature' as
> well, at least in some firmware.  Probably can reproduce by sending
> off-channel mgt frames on 5Ghz when associated on 2.4, or something
> similar to this.  I was using ath9k as sniffer when I found this long
> ago, so at least ath9k needs the change....

I don't see how this is related? It's not advertising those rates, so
it probably also can't use/report them as far as mac80211 and the rest
of the stack are concerned.

johannes

  reply	other threads:[~2016-10-04  9:32 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-06 19:00 [PATCH] cfg80211: cap 20MHz VHT bitrate at MCS 8 Thomas Pedersen
2016-09-06 19:07 ` Ben Greear
2016-09-07 18:20   ` Pedersen, Thomas
2016-09-12  6:43     ` Johannes Berg
2016-09-12 16:36       ` Ben Greear
2016-09-13 17:57       ` Pedersen, Thomas
2016-09-13 18:02         ` Johannes Berg
2016-09-16 18:31           ` Pedersen, Thomas
2016-09-19  9:00             ` Johannes Berg
2016-09-19  9:31               ` Arend Van Spriel
2016-09-19 16:19               ` Ben Greear
2016-10-04  9:32                 ` Johannes Berg [this message]
2016-10-04 16:31                   ` Ben Greear
2016-10-13 12:52                     ` Johannes Berg

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=1475573532.5324.47.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=greearb@candelatech.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=twp@qca.qualcomm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.