[PATCH] ath10k: Clean the HI_ACS_FLAGS_ALT_DATA_CREDIT_SIZE flag

[Kalle Valo]

Wen Gong <quic_wgong at quicinc.com> writes:

> On 11/24/2021 3:46 PM, Kalle Valo wrote:
>> Fabio Estevam <festevam at gmail.com> writes:
>>
>>> Hi Kalle,
>>>
>>> On Mon, Nov 15, 2021 at 3:06 PM Fabio Estevam <festevam at gmail.com> wrote:
>>>> Hi Kalle,
>>>>
>>>> On Wed, Sep 15, 2021 at 1:05 PM Fabio Estevam <festevam at denx.de> wrote:
>>>>> On an imx6dl-pico-pi board with a QCA9377 SDIO chip, the following
>>>>> errors are observed when the board works in STA mode:
>>>>>
>>>>> Simply running "ssh user at 192.168.0.1" causes:
>>>>>
>>>>> [   55.824159] ath10k_sdio mmc1:0001:1: failed to transmit packet, dropping: -12
>>>>> [   55.832169] ath10k_sdio mmc1:0001:1: failed to submit frame: -12
>>>>> [   55.838529] ath10k_sdio mmc1:0001:1: failed to push frame: -12
>>>>> [   55.905863] ath10k_sdio mmc1:0001:1: failed to transmit packet, dropping: -12
>>>>> [   55.913650] ath10k_sdio mmc1:0001:1: failed to submit frame: -12
>>>>> [   55.919887] ath10k_sdio mmc1:0001:1: failed to push frame: -12
>>>>>
>>>>> and it is not possible to connect via ssh to the other machine.
>>>>>
>>>>> One user inspected the size of frames on Wireshark and reported
>>>>> the followig:
>>>>>
>>>>> "I was able to narrow the issue down to the mtu. If I set the mtu for
>>>>> the wlan0 device to 1486 instead of 1500, the issue does not happen.
>>>>>
>>>>> The size of frames that I see on Wireshark is exactly 1500 after
>>>>> setting it to 1486."
>>>>>
>>>>> Clearing the HI_ACS_FLAGS_ALT_DATA_CREDIT_SIZE avoids the problem and
>>>>> the ssh command works successfully after that.
>>>>>
>>>>> Tested with QCA9377 SDIO with firmware WLAN.TF.1.1.1-00061-QCATFSWPZ-1.
>>>>>
>>>>> Fixes: 2f918ea98606 ("ath10k: enable alt data of TX path for sdio")
>>>>> Signed-off-by: Fabio Estevam <festevam at denx.de>
>>>> A gentle ping on this one.
>>> Any comments, please? Without this fix, we can not log via ssh to other machine.
>> I don't have much time for ath10k nowadays, so expect long delays in
>> reviews.
>>
>> I'm worried that this breaks QCA6174 SDIO support. Wen, what do you
>> think of this? Is this because of differences between firmware versions
>> or what?
>
> it is added by below commit, if disable it, will significant effect
> performance.

Thanks, I was worried it's something like this. One way to solve this
would be to add a new field to ath10k_hw_params so that the workaround
is done only on QCA9377 SDIO.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches