From: Kalle Valo <kvalo@qca.qualcomm.com>
To: Christian Lamparter <chunkeey@gmail.com>
Cc: Sebastian Gottschall <s.gottschall@dd-wrt.com>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH] ath10k: fix recent bandwidth conversion bug
Date: Mon, 20 Nov 2017 11:57:21 +0000 [thread overview]
Message-ID: <87tvxpf9i8.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <1666282.PC3nhpCf9f@debian64> (Christian Lamparter's message of "Thu, 02 Nov 2017 20:34:06 +0100")
Christian Lamparter <chunkeey@gmail.com> writes:
> On Wednesday, November 1, 2017 9:37:53 PM CET Sebastian Gottschall wrote:
>> a additional array bounds check would be good
>
> Ah, about that:
>
> the bw variable in ath10k_htt_rx_h_rates() is extracted from info2
> in the following way [0]:
> | bw =3D info2 & 3;
>
> the txrate.bw variable in ath10k_update_per_peer_tx_stats() is set by [1]=
:
> | txrate.bw =3D ATH10K_HW_BW(peer_stats->flags);
>
> ATH10K_HW_BW is a macro defined as [2]:
> | #define ATH10K_HW_BW(flags) (((flags) >> 3) & 0x3)
>
> In both cases the bandwidth values already are limited to 0-3 by
> the "and 3" operation.
Until someone changes that part of the code (and the firmware
interface). IMHO a switch is safer as there we don't have any risk of
out of bands access.
--=20
Kalle Valo=
next prev parent reply other threads:[~2017-11-20 11:57 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-01 20:01 [PATCH] ath10k: fix recent bandwidth conversion bug Christian Lamparter
2017-11-01 20:36 ` Sebastian Gottschall
2017-11-01 20:37 ` Sebastian Gottschall
2017-11-02 19:34 ` Christian Lamparter
2017-11-02 21:08 ` Sebastian Gottschall
2017-11-13 8:53 ` Johannes Berg
2017-11-20 11:57 ` Kalle Valo [this message]
2017-11-20 17:05 ` Christian Lamparter
2017-12-14 13:21 ` Kalle Valo
2018-03-01 11:52 ` Rafał Miłecki
2018-03-11 7:12 ` Kalle Valo
2018-03-11 21:01 ` Rafał Miłecki
-- strict thread matches above, loose matches on Subject: below --
2018-03-10 12:20 Anilkumar Kolli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87tvxpf9i8.fsf@kamboji.qca.qualcomm.com \
--to=kvalo@qca.qualcomm.com \
--cc=chunkeey@gmail.com \
--cc=linux-wireless@vger.kernel.org \
--cc=s.gottschall@dd-wrt.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).