ath10k: Handle "invalid" BDFs for msm8998 devices

When the BDF download QMI message has the end field set to 1, it signals
the end of the transfer, and triggers the firmware to do a CRC check.  The
BDFs for msm8998 devices fail this check, yet the firmware is happy to
still use the BDF.  It appears that this error is not caught by the
downstream drive by concidence, therefore there are production devices
in the field where this issue needs to be handled otherwise we cannot
support wifi on them.  So, attempt to detect this scenario as best we can
and treat it as non-fatal.

Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
This commit is contained in:
Jeffrey Hugo 2019-11-13 07:46:46 -08:00 committed by Kalle Valo
parent f8a595a87e
commit 319c2b7104

View File

@ -279,7 +279,15 @@ static int ath10k_qmi_bdf_dnld_send_sync(struct ath10k_qmi *qmi)
if (ret < 0)
goto out;
if (resp.resp.result != QMI_RESULT_SUCCESS_V01) {
/* end = 1 triggers a CRC check on the BDF. If this fails, we
* get a QMI_ERR_MALFORMED_MSG_V01 error, but the FW is still
* willing to use the BDF. For some platforms, all the valid
* released BDFs fail this CRC check, so attempt to detect this
* scenario and treat it as non-fatal.
*/
if (resp.resp.result != QMI_RESULT_SUCCESS_V01 &&
!(req->end == 1 &&
resp.resp.result == QMI_ERR_MALFORMED_MSG_V01)) {
ath10k_err(ar, "failed to download board data file: %d\n",
resp.resp.error);
ret = -EINVAL;