At one point, you could set a single rate using 'iw' and
ath10k would convert that to a special firmware API that
fixed all data traffic to a particular rate set. (Management
frames and broadcast will not be affected by setting the rates
when using ath10k).
But, with the commit below, a command like this will fail:
#iw dev vap206 set bitrates legacy-5 ht-mcs-5 0 vht-mcs-5
command failed: Invalid argument (-22)
But, it actually *does* successfully set the rate in the driver first, which
is confusing at best.
So, I think we should relax this check, at least for ath10k.
commit e8e4f5280ddd0a7b43a795f90a0758e3c99df6a6
Author: Johannes Berg <johannes.berg@xxxxxxxxx>
Date: Wed Mar 8 11:12:10 2017 +0100
mac80211: reject/clear user rate mask if not usable
If the user rate mask results in no (basic) rates being usable,
clear it. Also, if we're already operating when it's set, reject
it instead.
Technically, selecting basic rates as the criterion is a bit too
restrictive, but calculating the usable rates over all stations
(e.g. in AP mode) is harder, and all stations must support the
basic rates. Similarly, in client mode, the basic rates will be
used anyway for control frames.
This fixes the "no supported rates (...) in rate_mask ..." warning
that occurs on TX when you've selected a rate mask that's not
compatible with the connection (e.g. an AP that enables only the
rates 36, 48, 54 and you've selected only 6, 9, 12.)
Reported-by: Kirtika Ruchandani <kirtika@xxxxxxxxxx>
Signed-off-by: Johannes Berg <johannes.berg@xxxxxxxxx>
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
