netdev - Re: [PATCH] ath10k: Handle "invalid" BDFs for msm8998 devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOCk7NoXv2-8GO=VYS8dNPJF6sj=S3RbkfqQGW0kvvVmR8V1kw@mail.gmail.com>
Date:   Tue, 12 Nov 2019 08:53:51 -0700
From:   Jeffrey Hugo <jeffrey.l.hugo@...il.com>
To:     Simon Horman <simon.horman@...ronome.com>
Cc:     kvalo@...eaurora.org, davem@...emloft.net,
        ath10k@...ts.infradead.org, linux-wireless@...r.kernel.org,
        netdev@...r.kernel.org, MSM <linux-arm-msm@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ath10k: Handle "invalid" BDFs for msm8998 devices

On Tue, Nov 12, 2019 at 2:04 AM Simon Horman <simon.horman@...ronome.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@...il.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
> >