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 <[email protected]> --- drivers/net/wireless/ath/ath10k/qmi.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/qmi.c b/drivers/net/wireless/ath/ath10k/qmi.c index eb618a2652db..5ff8cfc93778 100644 --- a/drivers/net/wireless/ath/ath10k/qmi.c +++ b/drivers/net/wireless/ath/ath10k/qmi.c @@ -265,10 +265,13 @@ static int ath10k_qmi_bdf_dnld_send_sync(struct ath10k_qmi *qmi) goto out; if (resp.resp.result != QMI_RESULT_SUCCESS_V01) { - ath10k_err(ar, "failed to download board data file: %d\n", - resp.resp.error); - ret = -EINVAL; - goto out; + if (!(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; + goto out; + } } remaining -= req->data_len; -- 2.17.1 _______________________________________________ ath10k mailing list [email protected] http://lists.infradead.org/mailman/listinfo/ath10k
