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 ;) 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. Brian
