On Thursday 01 March 2012 05:12 PM, Mohammed Shafi Shajakhan wrote:
> On Thursday 01 March 2012 11:09 AM, Mohammed Shafi Shajakhan wrote:
>> Hi Christian,
>>
>> On Monday 27 February 2012 09:40 PM, Christian Lamparter wrote:
>>> With the new tx status API: "mac80211: implement wifi TX status"
>>> All skb originating from mac80211 needs to be given back to mac80211.
>>>
>>> Signed-off-by: Christian Lamparter<chunkeey@googlemail.com>
>>> ---
>>> It's high time we change all calls in the tx-path from
>>> dev_kfree_skb into ieee80211_free_txskb.
>>>
>>> The call in ath9k_tx is straightforward, but the one in
>>> ath_tx_setup_buffer gives me headaches. I'm not sure if
>>> we even need to check bf->bf_state.bfs_paprd at this
>>> stage since ath_tx_start_dma sets bf->bf_state.bfs_paprd
>>> "after" calling ath_tx_setup_buffer?!
>>
>> yes, i think its a problem, we cannot exactly say its the skb from
>> mac80211 (or) its our PAPRD skb. though with the current code(as the
>> PAPRD) is disabled the skb would be always from mac80211. let us see if
>> we have some good solution.
>
>
> got some idea, need to make sure this works perfectly, paprd frames are
> not aggregated, so we can look only at the non-aggregated path.
>
> lets ignore aggregated path:
>
> *ath_tx_form_aggr
> *ath_tx_send_ampdu
>
>
> non-aggregated path :
>
> *ath_tx_start_dma
> *ath_send_normal
>
> -> 'ath_tx_setup_buffer' called from 'ath_tx_start_dma' can have a
> 'is_paprd' check based on 'txctl->paprd' which holds which chain we are
> sending PAPRD frame.
>
> -> 'ath_send_normal' called from
> -ath_tx_start_dma ( then 'bf' should be valid and we would not have
> called 'ath_tx_setup_buffer'
> -ath_tx_flush_tid ( which is an aggregation path) ignore it.
>
>
> attached rough patch for ath9k, need to be compiled and tested. i will
> also analyze if this can be done in a better way or any flaws in it
>

compilation fails with previous patch, forgot to declare the field in 
the declaration, attached patch passes compilation.


-- 
thanks,
shafi