Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) client-ip=2620:137:e000::3:4;
Message-ID: <9485af8e-3379-f592-0e8f-0eaebf4fbc05@yandex.ru>
Date:   Thu, 14 Sep 2023 08:15:41 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.13.0
Content-Language: en-US
To:     Jeff Johnson <quic_jjohnson@quicinc.com>
Cc:     Kalle Valo <kvalo@kernel.org>, ath10k@lists.infradead.org,
        linux-wireless@vger.kernel.org
From:   Dmitry Antipov <dmantipov@yandex.ru>
Subject: On status handling in ath10k_htt_rx_tx_compl_ind()
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

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