| Message ID | 1418719980-19753-2-git-send-email-janusz.dziedzic@tieto.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
Janusz Dziedzic <janusz.dziedzic@tieto.com> writes: > Assoc peer command contain information about NSS. > When we will get IEEE80211_RC_NSS_CHANGED we should > also send (re) assoc peer command to be sure firmware > will know about it and RC will work correctly. > > Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com> Does this fix a user visible bug or is this something you just found from doing code review?
On 17 December 2014 at 11:32, Kalle Valo <kvalo@qca.qualcomm.com> wrote: > Janusz Dziedzic <janusz.dziedzic@tieto.com> writes: > >> Assoc peer command contain information about NSS. >> When we will get IEEE80211_RC_NSS_CHANGED we should >> also send (re) assoc peer command to be sure firmware >> will know about it and RC will work correctly. >> >> Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com> > > Does this fix a user visible bug or is this something you just found > from doing code review? > In case we will get only IEEE80211_RC_NSS_CHANGED we will not update FW configuration correctly. This is not the problem when IBSS, while we update two flags in one step IEEE80211_RC_SUPP_RATES_CHANGED | IEEE80211_RC_NSS_CHANGED. We could have problems when mac80211 will send only NSS_CHANGED flag. This seems could happen when we will get WLAN_EID_OPMODE_NOTIF. I didn't test such case, but I believe some AP could send such notification. So, this fix potential TP issue. BR Janusz -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Janusz Dziedzic <janusz.dziedzic@tieto.com> writes: > On 17 December 2014 at 11:32, Kalle Valo <kvalo@qca.qualcomm.com> wrote: >> Janusz Dziedzic <janusz.dziedzic@tieto.com> writes: >> >>> Assoc peer command contain information about NSS. >>> When we will get IEEE80211_RC_NSS_CHANGED we should >>> also send (re) assoc peer command to be sure firmware >>> will know about it and RC will work correctly. >>> >>> Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com> >> >> Does this fix a user visible bug or is this something you just found >> from doing code review? > > In case we will get only IEEE80211_RC_NSS_CHANGED we will not update > FW configuration correctly. This is not the problem when IBSS, while > we update two flags in one step IEEE80211_RC_SUPP_RATES_CHANGED | > IEEE80211_RC_NSS_CHANGED. > > We could have problems when mac80211 will send only NSS_CHANGED flag. > This seems could happen when we will get WLAN_EID_OPMODE_NOTIF. I > didn't test such case, but I believe some AP could send such > notification. So, this fix potential TP issue. Ok, I'll add to the commit log that this was found during code review (and doesn't fix a reported bug).
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index c9e7995..05fd620 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -3592,8 +3592,9 @@ static void ath10k_sta_rc_update_wk(struct work_struct *wk) sta->addr, smps, err); } - if (changed & IEEE80211_RC_SUPP_RATES_CHANGED) { - ath10k_dbg(ar, ATH10K_DBG_MAC, "mac update sta %pM supp rates\n", + if (changed & IEEE80211_RC_SUPP_RATES_CHANGED || + changed & IEEE80211_RC_NSS_CHANGED) { + ath10k_dbg(ar, ATH10K_DBG_MAC, "mac update sta %pM supp rates/nss\n", sta->addr); err = ath10k_station_assoc(ar, arvif->vif, sta, true);
Assoc peer command contain information about NSS. When we will get IEEE80211_RC_NSS_CHANGED we should also send (re) assoc peer command to be sure firmware will know about it and RC will work correctly. Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com> --- drivers/net/wireless/ath/ath10k/mac.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)