On 23 September 2014 18:48, Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote: > On 09/23/2014 01:59 AM, Michal Kazior wrote: >> On 23 September 2014 01:00, <greearb@xxxxxxxxxxxxxxx> wrote: >>> From: Ben Greear <greearb@xxxxxxxxxxxxxxx> [...] >>> @@ -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); [...] >> 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. ath9k doesn't have firmware and it doesn't have a blackbox rate control so maybe it doesn't need to worry about this as much as ath10k needs to. But then this is not something you normally use except some very specific use cases so I think it might not be worth the hassle to implement full-blown reconfig after chainmask is updated. > I would rather keep this requirement in user-space... > > I am not sure where to document this...just a comment in the code? Hmm.. Perhaps in ath10k_set_antenna? Or maybe we should just put it up on the wiki? But it's still probably a good idea to comment the quoted code chunk above explaining why nrf is overriden by chainmask (i.e. due to firmware rate control issues, right?). Michał -- 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
