On 05/25/2020 02:07 AM, Johannes Berg wrote:
On Wed, 2020-03-25 at 11:14 -0700, Brian Norris wrote:
On Wed, Mar 25, 2020 at 8:52 AM Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote:
On 03/24/2020 10:16 PM, Brian Norris wrote:
Sure, but if you mask out all but 1 bitrate...voila! A fixed rate!
So, see this thread from a while back. Has anyone even *tried* to use
this API you are proposing?
Yes, in fact, I have! Which is why I noted:
Now, there are other problems, like the others that Ben mentioned: the
rest of the mac80211 framework doesn't like it too much if you really
disable all but 1 rate (arguably a mac80211 bug -- but not a nl80211
bug)
http://lists.infradead.org/pipermail/ath10k/2017-October/010291.html
I hadn't seen that thread. So it sounds like maybe Johannes isn't
quite on the same page as Johannes ;)
Hah. Happens all the time, not sure what that other Johannes is thinking
;-)
More seriously though, I'm a bit lost now (and a big part of that is
probably because I'm replying to a 2 months old thread, sorry).
If we're going to be particular about matching the AP's basic rates,
then this API is indeed probably not useful for the "single fixed rate
[for debugging/testing]" use case.
mac80211: Revert some of e8e4f5, fixes setting single rate in ath10k.
Commit e8e4f5 was an unfortunate consequence of the stuff I mentioned
earlier about how Chrome OS used to use SET_TX_BITRATE_MAX -- we
weren't nuanced about it at all, so we might configure a set of
bitrates that doesn't intersect at all with the AP's BasicRates. That
does make it hard for the driver/framework to decide what to do: do we
listen to the user, or to the AP? Incidentally, that's also one reason
why Chrome OS no longer uses the API; it was too big of a hammer for
what we want (initial-connection reliability), and required us to be
more delicate about {Supported,Basic}Rates than we really wanted to.
Right.
But I'm not sure why Ben needs to just do a pr_err()? Shouldn't that
just not happen?
Try setting a single rate on ath10k. It will not work unless you add my
patch.
I put a pr_err in there because you (or whoever pushed the regression upstream)
thought it was a problem to set a single rate, so I wanted to warn the user
but also let the action work.
Thanks,
Ben
Hmm.
johannes
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
