On 09/23/2014 01:59 AM, Michal Kazior wrote: > On 23 September 2014 01:00, <greearb@xxxxxxxxxxxxxxx> wrote: >> From: Ben Greear <greearb@xxxxxxxxxxxxxxx> >> >> When re-associating a station, the nss was set back to >> maximum value even if user had configured small number >> of tx chains. So, pay attention to user's config in >> this case as well. >> >> Signed-off-by: Ben Greear <greearb@xxxxxxxxxxxxxxx> >> --- >> drivers/net/wireless/ath/ath10k/mac.c | 11 +++++++++-- >> 1 file changed, 9 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c >> index 855c71c..c5d31cc 100644 >> --- a/drivers/net/wireless/ath/ath10k/mac.c >> +++ b/drivers/net/wireless/ath/ath10k/mac.c >> @@ -4086,6 +4086,10 @@ ath10k_default_bitrate_mask(struct ath10k *ar, >> u32 legacy = 0x00ff; >> u8 ht = 0xff, i; >> u16 vht = 0x3ff; >> + u16 nrf = ar->num_rf_chains; >> + >> + if (ar->cfg_tx_chainmask) >> + nrf = get_nss_from_chainmask(ar->cfg_tx_chainmask); > > Oh, so you do update the peer nss value here. Yeah, I found this was needed in further testing yesterday... > I think it might be a good idea to convey the limitation of tx/rx > chainmask to the user: you can't change the tx/rx chainmask on the fly > easily (while connected/have associated stations). Or do you plan to > schedule peer reassoc in __ath10k_set_antenna() in a follow up > patch(es) later? My user-space tools assume you have to re-connect (requested from user-space) after changing the chainmask. I was under the impression that this is how ath9k works, though I could be wrong. I would rather keep this requirement in user-space... I am not sure where to document this...just a comment in the code? Thanks, Ben -- Ben Greear <greearb@xxxxxxxxxxxxxxx> Candela Technologies Inc http://www.candelatech.com -- 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
