Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) client-ip=23.128.96.31;
Message-ID: <18eac255-720a-488e-882e-b79f098aba65@quicinc.com>
Date:   Thu, 14 Sep 2023 08:38:08 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: On status handling in ath10k_htt_rx_tx_compl_ind()
Content-Language: en-US
To:     Dmitry Antipov <dmantipov@yandex.ru>
CC:     Kalle Valo <kvalo@kernel.org>, <ath10k@lists.infradead.org>,
        <linux-wireless@vger.kernel.org>
References: <9485af8e-3379-f592-0e8f-0eaebf4fbc05@yandex.ru>
From:   Jeff Johnson <quic_jjohnson@quicinc.com>
In-Reply-To: <9485af8e-3379-f592-0e8f-0eaebf4fbc05@yandex.ru>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 9/13/2023 10:15 PM, Dmitry Antipov wrote:
> In 'ath10k_htt_rx_tx_compl_ind()',
> 
> int status = MS(resp->data_tx_completion.flags, HTT_DATA_TX_STATUS);
> 
> actually is
> 
> int status = (((resp->data_tx_completion.flags) & 0x07) >> 0);
> 
> which can't be equal to HTT_DATA_TX_STATUS_DOWNLOAD_FAIL (128)
> regardless of the 'data_tx_completion.flags' value. This is most
> likely a weird (but I have no clue how serious it may be) bug.
> 
> Dmitry

Looking at firmware code I don't see any reference to a "download fail" 
status so I don't think firmware would ever send such a status.

If you want to submit a patch, the correct fix is to remove all 
references to HTT_DATA_TX_STATUS_DOWNLOAD_FAIL.

/jeff