| Message ID | 20180228004525.5156-1-bjorn.andersson@linaro.org |
|---|---|
| State | Accepted |
| Commit | 90c29ed7627b6b4aeb603ee197650173c8434512 |
| Headers | show |
| Series | soc: qcom: wcnss_ctrl: Fix increment in NV upload | expand |
diff --git a/drivers/soc/qcom/wcnss_ctrl.c b/drivers/soc/qcom/wcnss_ctrl.c index e968559b0fc4..5429c91440b1 100644 --- a/drivers/soc/qcom/wcnss_ctrl.c +++ b/drivers/soc/qcom/wcnss_ctrl.c @@ -249,7 +249,7 @@ static int wcnss_download_nv(struct wcnss_ctrl *wcnss, bool *expect_cbc) /* Increment for next fragment */ req->seq++; - data += req->hdr.len; + data += NV_FRAGMENT_SIZE; left -= NV_FRAGMENT_SIZE; } while (left > 0);
hdr.len includes both the size of the header and the fragment, so using this when stepping through the firmware causes us to skip 16 bytes every chunk of 3072 bytes; causing only the first fragment to actually be valid data. Instead use fragment size steps through the firmware blob. Fixes: ea7a1f275cf0 ("soc: qcom: Introduce WCNSS_CTRL SMD client") Reported-by: Will Newton <will.newton@gmail.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> --- It's worth noting that the firmware does not complain about the broken NV blob nor does fixing this seem to alter the behavior of BT or WLAN - perhaps because the WLAN driver uploads the NV blob as well? drivers/soc/qcom/wcnss_ctrl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.16.2 -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html