[PATCH 1/3] wifi: ath11k: fix dest ring-buffer corruption

[Miaoqing Pan]

On 6/6/2025 10:02 AM, Baochen Qiang wrote:
> 
> 
> On 6/6/2025 8:52 AM, Miaoqing Pan wrote:
>>
>>
>> On 6/5/2025 6:54 PM, Baochen Qiang wrote:
>>>
>>>
>>> On 6/5/2025 6:17 PM, Johan Hovold wrote:
>>>> On Thu, Jun 05, 2025 at 12:01:29PM +0800, Miaoqing Pan wrote:
>>>>> On 6/5/2025 12:24 AM, Jeff Johnson wrote:
>>>>>> On 6/3/2025 7:34 PM, Miaoqing Pan wrote:
>>>>>>> We previously had extensive discussions on this topic in the
>>>>>>> https://lore.kernel.org/linux-wireless/ecfe850c-b263-4bee-b888-
>>>>>>> c34178e690fc at quicinc.com/
>>>>>>> thread. On my platform, dma_rmb() did not work as expected. The issue
>>>>>>> only disappeared after disabling PCIe endpoint relaxed ordering in
>>>>>>> firmware side. So it seems that HP was updated (Memory write) before
>>>>>>> descriptor (Memory write), which led to the problem.
>>>>>>
>>>>>> Have all ath11k and ath12k firmware been updated to prevent this problem from
>>>>>> the firmware side?
>>>>>>
>>>>> No, as this is not a widespread issue, and addressing it would require
>>>>> modifying the core underlying modules of the firmware. Therefore, we
>>>>> chose not to proceed with that approach but instead used the workaround
>>>>> patch I previously submitted.
>>>
>>> If firmware has a concern, how about doing it in host? As I know it is only a register in
>>> PCI config space?
>>>
>>
>> No, host can only configure the RC, while the initialization of the EP can only be
>> configured on the firmware side.
> 
> Are you talking about this specific register or whole configuration space? If it is the
> latter case we already have something similar (such as disabling ASPM) done in host side.
> Just curious why not for your issue.
> 

ath11k_pci_aspm_disable() disables ASPM for RC, not works here. But we 
can configured via WMI, which was one of our previous fix options. If 
there are new questions, we can discuss internally.


>>
>>>>
>>>> I strongly suggest you fix this at the firmware level rather than try to
>>>> work around it in the kernel to avoid playing whack-a-mole whenever a
>>>> new (hard to track down) bug shows up.
>>>>
>>>> The barriers should be enough, but if they are not then the firmware
>>>> must be fixed.
>>>>
>>>> Johan
>>>
>> This is beyond our control. After nearly three months of effort, we have decided to
>> abandon it.
>>
>