On 8 March 2016 at 12:54, Rajkumar Manoharan <rmanohar@xxxxxxxxxxxxxxxx> wrote:
[...]
> +int ath10k_htt_tx_mgmt_inc_pending(struct ath10k_htt *htt, bool is_mgmt,
> + bool is_presp)
> {
> struct ath10k *ar = htt->ar;
>
> lockdep_assert_held(&htt->tx_lock);
>
> + if (!is_mgmt)
> + return 0;
> +
> if (htt->num_pending_tx >= htt->max_num_pending_tx)
> return -EBUSY;
This busy here will be hit when you use last tx slot because
tx_inc_pending() is called before tx_mgmt_inc_pending().
[...]
> skb_cb = ATH10K_SKB_CB(msdu);
> txq = skb_cb->txq;
> artxq = (void *)txq->drv_priv;
>
> - if (unlikely(skb_cb->flags & ATH10K_SKB_F_MGMT) &&
> - ar->hw_params.max_probe_resp_desc_thres)
> - limit_mgmt_desc = true;
> -
Oh wait.. I didn't pay attention before, but this looks rather ugly.
With this you will actually make the num_pending_mgmt_tx spin
endlessly upwards on firmware with HTT 3.0 (and uses TX_FRM for mgmt
tx and TX_COMPL_IND for completions), no?
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
