Hi Jouni, > Where is that mrr[3] part implemented? I did not find it when reviewing > the design (hw->max_rates >= 3 is used, but not >= 4) and this does not > match my experiments either when printing out all four values from > ath9k. In every single case I observed, the last entry was unused (idx = > -1) and only MCS values were used (i.e., not even a single case of basic > rate visible; basic rates being 6, 12, 24 Mbps OFDM in this specific > case with the AP that I used in the tests). Minstrel_HT does only set mrr[0..2] and does not touch the fourth mrr[3], assumed chips with 4 mrr stages. In function minstrel_ht_update_rates() the rate table struct ieee80211_sta_rates is set for the first 3 out of 4 rates and the fouth rate (mrr[3]) is „-1“. In case of ath9k, the driver in xmit.c allocates in function ath_tx_fill_desc() a struct ath_tx_info info by memset(&info, 0, sizeof(info)) .. so all info->rates[xy].Rate == 0. Than function ath_buf_set_rate() sets all info->rates[xy].Rate to those values specified in the rate table (struct ieee8021_sta_rate) IF (!rates[i].count || (rates[i].idx < 0)) … … so info->rates[3].Rate is untouched and still „0“. I just added a printk() to xmit.c in function ath_tx_fill_desc() just before ath9k_hw_set_txdesc() is called. >From the log I get, e.g.: [ 169.543554] mrr setup: mrr[0]:133 mrr[1]:132 mrr[2]:134 mrr[3]:0 I have not check yet if info->rates[3].Rate == 0 is the lowest possible rate… but I would guess so. Greetings Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
