Message ID | 20191113154646.43048-1-jeffrey.l.hugo@gmail.com (mailing list archive) |
---|---|
State | Accepted |
Commit | 319c2b71041f324e06dbee03c1011106cf746795 |
Headers | show |
Series | [v2] ath10k: Handle "invalid" BDFs for msm8998 devices | expand |
Jeffrey Hugo <jeffrey.l.hugo@gmail.com> wrote: > 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> Patch applied to ath-next branch of ath.git, thanks. 319c2b71041f ath10k: Handle "invalid" BDFs for msm8998 devices
diff --git a/drivers/net/wireless/ath/ath10k/qmi.c b/drivers/net/wireless/ath/ath10k/qmi.c index 637f83ef65f8..6df2d3ac5474 100644 --- a/drivers/net/wireless/ath/ath10k/qmi.c +++ b/drivers/net/wireless/ath/ath10k/qmi.c @@ -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;