Michal Kazior <michal.kaz...@tieto.com> writes: > On 23 September 2014 16:19, Ben Greear <gree...@candelatech.com> wrote: >> On 09/23/2014 02:16 AM, Michal Kazior wrote: >>> On 19 September 2014 20:28, <gree...@candelatech.com> wrote: >>> [...] >>>> >>>> + /* If we are CT firmware, ask it to flush all tids on all peers >>>> on >>>> + * all vdevs. Normal firmware will just crash if you do this. >>>> + */ >>>> + if (test_bit(ATH10K_FW_FEATURE_WMI_10X_CT, ar->fw_features)) >>>> + ath10k_wmi_peer_flush(ar, 0xFFFFFFFF, peer_addr, >>>> 0xFFFFFFFF); >>> >>> I recall you've explained this some time ago, but can you refresh my >>> memory, please? Is this any different from iterating over all peers >>> and flushing each? Or does your firmware do so extra magic that is >>> impossible to do with normal firmware commands? >> >> My firmware does that iteration internally. >> >> You could probably do that in the driver, but it would be a lot >> of messages (for all vdevs, all peers, all tids)... >> I was not sure if there were limits to the number >> of commands you should attempt during the flush... > > Thanks. I think ath10k should do this instead of having CT-specific > flush eventually.
I agree. We should not be forking functionality unless absolutely necessary. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
