Commit 0c86980817853e4166f66c7cd18bc5fe1adeb5f7

Authored by Juuso Oikarinen
Committed by John W. Linville
1 parent 5af5542885

mac80211: Fix sta->last_tx_rate setting with no-op rate control devices

The sta->last_tx_rate is traditionally updated just before transmitting a
frame based on information from the rate control algorithm. However, for
hardware drivers with IEEE80211_HW_HAS_RATE_CONTROL this is not performed,
as the rate control algorithm is not executed, and because the used rate is
not known before the frame has actually been transmitted.

This causes atleast a fixed 1Mb/s to be reported to user space. A few other
instances of code also rely on this information.

Fix this by setting the sta->last_tx_rate in tx_status handling. There, look
for last rates entry set by the driver, and use that as value for
sta->last_tx_rate.

Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Showing 1 changed file with 7 additions and 0 deletions Side-by-side Diff

net/mac80211/status.c
... ... @@ -171,6 +171,7 @@
171 171 struct net_device *prev_dev = NULL;
172 172 struct sta_info *sta, *tmp;
173 173 int retry_count = -1, i;
  174 + int rates_idx = -1;
174 175 bool send_to_cooked;
175 176  
176 177 for (i = 0; i < IEEE80211_TX_MAX_RATES; i++) {
... ... @@ -178,6 +179,8 @@
178 179 if (i >= hw->max_rates) {
179 180 info->status.rates[i].idx = -1;
180 181 info->status.rates[i].count = 0;
  182 + } else if (info->status.rates[i].idx >= 0) {
  183 + rates_idx = i;
181 184 }
182 185  
183 186 retry_count += info->status.rates[i].count;
... ... @@ -205,6 +208,10 @@
205 208 rcu_read_unlock();
206 209 return;
207 210 }
  211 +
  212 + if ((local->hw.flags & IEEE80211_HW_HAS_RATE_CONTROL) &&
  213 + (rates_idx != -1))
  214 + sta->last_tx_rate = info->status.rates[rates_idx];
208 215  
209 216 if ((info->flags & IEEE80211_TX_STAT_AMPDU_NO_BACK) &&
210 217 (ieee80211_is_data_qos(fc))) {