On Wed 06 Nov 15:47 PST 2019, Jeffrey Hugo 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 <[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)) {
Perhaps worth adding a comment in the code as well, to describe what scenario this relates to? Reviewed-by: Bjorn Andersson <[email protected]> Regards, Bjorn > + 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
