* [PATCH] ath10k: Handle "invalid" BDFs for msm8998 devices
@ 2019-11-06 23:47 Jeffrey Hugo
2019-11-12 9:04 ` Simon Horman
2019-11-12 19:08 ` Bjorn Andersson
0 siblings, 2 replies; 6+ messages in thread
From: Jeffrey Hugo @ 2019-11-06 23:47 UTC (permalink / raw)
To: kvalo, davem
Cc: ath10k, linux-wireless, netdev, linux-arm-msm, linux-kernel,
Jeffrey Hugo
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>
---
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
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] ath10k: Handle "invalid" BDFs for msm8998 devices
2019-11-06 23:47 [PATCH] ath10k: Handle "invalid" BDFs for msm8998 devices Jeffrey Hugo
@ 2019-11-12 9:04 ` Simon Horman
2019-11-12 15:53 ` Jeffrey Hugo
2019-11-12 19:08 ` Bjorn Andersson
1 sibling, 1 reply; 6+ messages in thread
From: Simon Horman @ 2019-11-12 9:04 UTC (permalink / raw)
To: Jeffrey Hugo
Cc: kvalo, davem, ath10k, linux-wireless, netdev, linux-arm-msm,
linux-kernel
On Wed, Nov 06, 2019 at 03:47:12PM -0800, 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 <jeffrey.l.hugo@gmail.com>
> ---
> 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)) {
Would it make sense to combine the inner and outer condition,
something like this (completely untested) ?
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;
> + goto out;
> + }
> }
>
> remaining -= req->data_len;
> --
> 2.17.1
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] ath10k: Handle "invalid" BDFs for msm8998 devices
2019-11-12 9:04 ` Simon Horman
@ 2019-11-12 15:53 ` Jeffrey Hugo
2019-11-13 4:58 ` Kalle Valo
0 siblings, 1 reply; 6+ messages in thread
From: Jeffrey Hugo @ 2019-11-12 15:53 UTC (permalink / raw)
To: Simon Horman; +Cc: kvalo, davem, ath10k, linux-wireless, netdev, MSM, lkml
On Tue, Nov 12, 2019 at 2:04 AM Simon Horman <simon.horman@netronome.com> wrote:
>
> On Wed, Nov 06, 2019 at 03:47:12PM -0800, 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 <jeffrey.l.hugo@gmail.com>
> > ---
> > 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)) {
>
> Would it make sense to combine the inner and outer condition,
> something like this (completely untested) ?
I guess, make sense from what perspective? Looks like the assembly
ends up being the same, so it would be down to "readability" which is
subjective - I personally don't see a major advantage to one way or
the other. It does look like Kalle already picked up this patch, so
I'm guessing that if folks feel your suggestion is superior, then it
would need to be a follow on.
>
> 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;
> > + goto out;
> > + }
> > }
> >
> > remaining -= req->data_len;
> > --
> > 2.17.1
> >
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] ath10k: Handle "invalid" BDFs for msm8998 devices
2019-11-06 23:47 [PATCH] ath10k: Handle "invalid" BDFs for msm8998 devices Jeffrey Hugo
2019-11-12 9:04 ` Simon Horman
@ 2019-11-12 19:08 ` Bjorn Andersson
1 sibling, 0 replies; 6+ messages in thread
From: Bjorn Andersson @ 2019-11-12 19:08 UTC (permalink / raw)
To: Jeffrey Hugo
Cc: kvalo, davem, ath10k, linux-wireless, netdev, linux-arm-msm,
linux-kernel
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 <jeffrey.l.hugo@gmail.com>
> ---
> 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 <bjorn.andersson@linaro.org>
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
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] ath10k: Handle "invalid" BDFs for msm8998 devices
2019-11-12 15:53 ` Jeffrey Hugo
@ 2019-11-13 4:58 ` Kalle Valo
2019-11-13 7:00 ` Simon Horman
0 siblings, 1 reply; 6+ messages in thread
From: Kalle Valo @ 2019-11-13 4:58 UTC (permalink / raw)
To: Jeffrey Hugo
Cc: Simon Horman, davem, ath10k, linux-wireless, netdev, MSM, lkml
Jeffrey Hugo <jeffrey.l.hugo@gmail.com> writes:
> On Tue, Nov 12, 2019 at 2:04 AM Simon Horman <simon.horman@netronome.com> wrote:
>>
>> On Wed, Nov 06, 2019 at 03:47:12PM -0800, 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 <jeffrey.l.hugo@gmail.com>
>> > ---
>> > 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)) {
>>
>> Would it make sense to combine the inner and outer condition,
>> something like this (completely untested) ?
>
> I guess, make sense from what perspective? Looks like the assembly
> ends up being the same, so it would be down to "readability" which is
> subjective - I personally don't see a major advantage to one way or
> the other. It does look like Kalle already picked up this patch, so
> I'm guessing that if folks feel your suggestion is superior, then it
> would need to be a follow on.
Same here, it's only on the pending branch so changes are still
possible.
--
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] ath10k: Handle "invalid" BDFs for msm8998 devices
2019-11-13 4:58 ` Kalle Valo
@ 2019-11-13 7:00 ` Simon Horman
0 siblings, 0 replies; 6+ messages in thread
From: Simon Horman @ 2019-11-13 7:00 UTC (permalink / raw)
To: Kalle Valo; +Cc: Jeffrey Hugo, davem, ath10k, linux-wireless, netdev, MSM, lkml
On Wed, Nov 13, 2019 at 06:58:25AM +0200, Kalle Valo wrote:
> Jeffrey Hugo <jeffrey.l.hugo@gmail.com> writes:
>
> > On Tue, Nov 12, 2019 at 2:04 AM Simon Horman <simon.horman@netronome.com> wrote:
> >>
> >> On Wed, Nov 06, 2019 at 03:47:12PM -0800, 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 <jeffrey.l.hugo@gmail.com>
> >> > ---
> >> > 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)) {
> >>
> >> Would it make sense to combine the inner and outer condition,
> >> something like this (completely untested) ?
> >
> > I guess, make sense from what perspective? Looks like the assembly
> > ends up being the same, so it would be down to "readability" which is
> > subjective - I personally don't see a major advantage to one way or
> > the other. It does look like Kalle already picked up this patch, so
> > I'm guessing that if folks feel your suggestion is superior, then it
> > would need to be a follow on.
My feeling is that it would reduce the churn in the patch making the
patch more readable and likewise improving the readability of the code.
But I do agree this does not affect run-time and I am ambivalent about
updating the patch if it has already been (semi-)accepted.
>
> Same here, it's only on the pending branch so changes are still
> possible.
>
> --
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-11-13 7:00 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-06 23:47 [PATCH] ath10k: Handle "invalid" BDFs for msm8998 devices Jeffrey Hugo
2019-11-12 9:04 ` Simon Horman
2019-11-12 15:53 ` Jeffrey Hugo
2019-11-13 4:58 ` Kalle Valo
2019-11-13 7:00 ` Simon Horman
2019-11-12 19:08 ` Bjorn Andersson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).