[PATCH] ath10k: request firmware flush in ath10k_flush.

Michal Kazior michal.kazior at tieto.com
Tue Sep 23 23:50:38 PDT 2014

On 23 September 2014 16:19, Ben Greear <greearb at candelatech.com> wrote:
> On 09/23/2014 02:16 AM, Michal Kazior wrote:
>> On 19 September 2014 20:28,  <greearb at 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 recall I actually did per-peer flushing in RFC patches a long time
ago but I didn't pursue getting them merged. I think Denton uses these
patches in his setup. They don't flush vdev self-peers though (do you
do that internally?).


More information about the ath10k mailing list