[ath9k-devel] [RFC 1/2] ath9k: use ieee80211_free_txskb

[Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>]

Hi Christian,

ping

On Thursday 01 March 2012 07:16 PM, Mohammed Shafi Shajakhan wrote:
> 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.
>
>

would you like me to test this patch, i can just ran a bidirectional 
traffic test parallel y enabling PAPRD,with this proposed patch.

-- 
thanks,
shafi