> On Apr 28, 2024, at 8:54 PM, Meiyong Yu <meiyong.yu@xxxxxxx> wrote:
>
>
>
>> On Apr 28, 2024, at 6:46 AM, Jeff Johnson <quic_jjohnson@xxxxxxxxxxx> wrote:
>>
>> On 4/27/2024 2:12 AM, Tamizh Chelvam Raja wrote:
>>> From: Venkateswara Naralasetty <quic_vnaralas@xxxxxxxxxxx>
>>>
>>> If STATUS_BUFFER_DONE is not set for a monitor status ring entry,
>>> we don't process the status ring until STATUS_BUFFER_DONE set
>>> for that status ring entry.
>>>
>>> During LMAC reset it may happen that hardware will not write
>>> STATUS_BUFFER_DONE tlv in status buffer, in that case we end up
>>> waiting for STATUS_BUFFER_DONE leading to backpressure on monitor
>>> status ring.
>>>
>
> Can you known the LMAC reset event, if you can known, you can set all the ring entry
> status to done after reset is done, and the logic of code will be more clear.
>
If sene of the LMAC reset event is asynchronous, You can do this:
1) when LMAC init than set a value to the new add global variabe lmac_life_cycle_id
2) before add tlv to ring, set lmac_life_cycle_id to tlv
3) when LMAC reset event is trigger, increase the value of lmac_life_cycle_id
4) when get the status of tlv in ring(must delay for same period to ensure the real send ring is already send),
check the value lmac_life_cycle_id in tlv, if it smaller than the global one set tlv status to DONE
>>> To fix the issue, when HP(Head Pointer) + 1 entry is peeked and if DMA
>>> is not done and if HP + 2 entry's DMA done is set,
>>> replenish HP + 1 entry and start processing in next interrupt.
>>> If HP + 2 entry's DMA done is not set, poll onto HP + 1 entry DMA
>>> done to be set.
>>>
>>> Also, during monitor attach HP points to the end of the ring and
>>> TP(Tail Pointer) points to the start of the ring.
>>> Using ath11k_hal_srng_src_peek() may result in processing invalid buffer
>>> for the very first interrupt. Since, HW starts writing buffer from TP.
>>>
>>> To avoid this issue call ath11k_hal_srng_src_next_peek() instead of
>>> calling ath11k_hal_srng_src_peek().
>>>
>>> Tested-on: IPQ5018 hw1.0 AHB WLAN.HK.2.6.0.1-00861-QCAHKSWPL_SILICONZ-1
>>>
>>> Reported-by: kernel test robot <lkp@xxxxxxxxx>
>>> Closes: https://lore.kernel.org/oe-kbuild-all/202303281719.CvnPkOiK-lkp@xxxxxxxxx/
>>
>> I believe these are misleading. LKP didn't find the problem you are fixing, it
>> found a problem in the implementation of the patch.
>> So I would move these below the "---" so the LKP knows the issue it found is
>> fixed, but the git history isn't itself isn't misleading
>>
>>> Signed-off-by: Venkateswara Naralasetty <quic_vnaralas@xxxxxxxxxxx>
>>> Co-developed-by: Tamizh Chelvam Raja <quic_tamizhr@xxxxxxxxxxx>
>>> Signed-off-by: Tamizh Chelvam Raja <quic_tamizhr@xxxxxxxxxxx>
>>> ---
>>> v3:
>>> * Rebased on top of ToT
>>> v2:
>>> * Fixed compilation warning Reported-by: kernel test robot <lkp@xxxxxxxxx>
>>>
>>> drivers/net/wireless/ath/ath11k/dp_rx.c | 88 ++++++++++++++++++++++---
>>> drivers/net/wireless/ath/ath11k/hal.c | 14 ++++
>>> drivers/net/wireless/ath/ath11k/hal.h | 2 +
>>
>> My Qualcomm Innovation Center copyright checker reports:
>> drivers/net/wireless/ath/ath11k/dp_rx.c copyright missing 2024
>> drivers/net/wireless/ath/ath11k/hal.c copyright missing 2024
>>
>
