wifi: mwifiex: Refactor 1-element array into flexible array in struct mwifiex_ie_types_chan_list_param_set

struct mwifiex_ie_types_chan_list_param_set::chan_scan_param is treated
as a flexible array, so convert it into one so that it doesn't trip
the array bounds sanitizer[1]. Only a few places were using sizeof()
on the whole struct, so adjust those to follow the calculation pattern
to avoid including the trailing single element.

Examining binary output differences doesn't appear to show any literal
size values changing, though it is obfuscated a bit by the compiler
adjusting register usage and stack spill slots, etc.

Link: https://github.com/KSPP/linux/issues/51 [1]
Cc: Brian Norris <briannorris@chromium.org>
Cc: Kalle Valo <kvalo@kernel.org>
Cc: Dmitry Antipov <dmantipov@yandex.ru>
Cc: Johannes Berg <johannes.berg@intel.com>
Cc: zuoqilin <zuoqilin@yulong.com>
Cc: Ruan Jinjie <ruanjinjie@huawei.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
Cc: linux-wireless@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20240207103024.make.423-kees@kernel.org

wifi: mwifiex: fix loop iterator in mwifiex_update_ampdu_txwinsize()

This code re-uses "i" to be the iterator for both the inside and outside
loops. It means the outside loop will exit earlier than intended.

Fixes: d219b7eb3792 ("mwifiex: handle BT coex event to adjust Rx BA window size")
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/Y+ERnaDaZD7RtLvX@kili

treewide: Replace GPLv2 boilerplate/reference with SPDX - gpl-2.0_391.RULE

Based on the normalized pattern:

this software file (the file ) is distributed by nxp under the terms
of the gnu general public license version 2 june 1991 (the license )
you may use redistribute and/or modify this file in accordance with
the terms and conditions of the license a copy of which is available
by writing to the free software foundation inc 51 franklin street
fifth floor boston ma 02110-1301 usa or on the worldwide web at
http://www gnu org/licenses/old-licenses/gpl-2 0 txt the file is
distributed as-is without warranty of any kind and the implied
warranties of merchantability or fitness for a particular purpose are
expressly disclaimed the license provides additional details about
this warranty disclaimer

extracted by the scancode license scanner the SPDX license identifier

GPL-2.0-only

has been chosen to replace the boilerplate/reference.

Reviewed-by: Allison Randal <allison@lohutok.net>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mwifiex: Send DELBA requests according to spec

While looking at on-air packets using Wireshark, I noticed we're never
setting the initiator bit when sending DELBA requests to the AP: While
we set the bit on our del_ba_param_set bitmask, we forget to actually
copy that bitmask over to the command struct, which means we never
actually set the initiator bit.

Fix that and copy the bitmask over to the host_cmd_ds_11n_delba command
struct.

Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver")
Signed-off-by: Jonas Dreßler <verdre@v0yd.nl>
Acked-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211016153244.24353-5-verdre@v0yd.nl

mwifiex: Fix an incorrect comment

We're sending DELBA requests here, not ADDBA requests.

Signed-off-by: Jonas Dreßler <verdre@v0yd.nl>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211016153244.24353-4-verdre@v0yd.nl

mwifiex: change license text from MARVELL to NXP

As of 6-DEC-2019, NXP has acquired Marvell’s Wireless business
unit. This change is to update the license text accordingly.

Signed-off-by: James Cao <zheng.cao@nxp.com>
Signed-off-by: Cathy Luo <xiaohua.luo@nxp.com>
Signed-off-by: Ganapathi Bhat <ganapathi.bhat@nxp.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

mwifiex: don't disable hardirqs; just softirqs

main_proc_lock and int_lock (in mwifiex_adapter) are the only spinlocks
used in hardirq contexts. The rest are only in task or softirq contexts.

Convert every other lock from *_irq{save,restore}() variants to _bh()
variants.

This is a mechanical transformation of all spinlock usage in mwifiex
using the following:

Step 1:
I ran this nasty sed script:

sed -i -E '/spin_lock_irqsave|spin_unlock_irqrestore/ {
/main_proc_lock|int_lock/! {
s:(spin_(un|)lock)_irq(save|restore):\1_bh: ;
# Join broken lines.
:a /;$/! {
N;
s/\s*\n\s*//;
ba
}
/,.*\);$/ s:,.*\):\):
}
}' drivers/net/wireless/marvell/mwifiex/*

Step 2:
Manually delete the flags / ra_list_flags args from:

mwifiex_send_single_packet()
mwifiex_11n_aggregate_pkt()
mwifiex_send_processed_packet()

which are now unused.

Step 3:
Apply this semantic patch (coccinelle) to remove the unused 'flags'
variables:

// <smpl>
@@
type T;
identifier i;
@@

(
extern T i;
|
- T i;
... when != i
)
// </smpl>

(Usage is something like this:

make coccicheck COCCI=./patch.cocci MODE=patch M=drivers/net/wireless/marvell/mwifiex/

although this skips *.h files for some reasons, so I had to massage
stuff.)

Testing: I've played with a variety of stress tests, including download
stress tests on the same APs which caught regressions with commit
5188d5453bc9 ("mwifiex: restructure rx_reorder_tbl_lock usage"). I've
primarily tested on Marvell 8997 / PCIe, although I've given 8897 / SDIO
a quick spin as well.

Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Revert "mwifiex: restructure rx_reorder_tbl_lock usage"

This reverts commit 5188d5453bc9380ccd4ae1086138dd485d13aef2, because it
introduced lock recursion:

BUG: spinlock recursion on CPU#2, kworker/u13:1/395
lock: 0xffffffc0e28a47f0, .magic: dead4ead, .owner: kworker/u13:1/395, .owner_cpu: 2
CPU: 2 PID: 395 Comm: kworker/u13:1 Not tainted 4.20.0-rc4+ #2
Hardware name: Google Kevin (DT)
Workqueue: MWIFIEX_RX_WORK_QUEUE mwifiex_rx_work_queue [mwifiex]
Call trace:
dump_backtrace+0x0/0x140
show_stack+0x20/0x28
dump_stack+0x84/0xa4
spin_bug+0x98/0xa4
do_raw_spin_lock+0x5c/0xdc
_raw_spin_lock_irqsave+0x38/0x48
mwifiex_flush_data+0x2c/0xa4 [mwifiex]
call_timer_fn+0xcc/0x1c4
run_timer_softirq+0x264/0x4f0
__do_softirq+0x1a8/0x35c
do_softirq+0x54/0x64
netif_rx_ni+0xe8/0x120
mwifiex_recv_packet+0xfc/0x10c [mwifiex]
mwifiex_process_rx_packet+0x1d4/0x238 [mwifiex]
mwifiex_11n_dispatch_pkt+0x190/0x1ac [mwifiex]
mwifiex_11n_rx_reorder_pkt+0x28c/0x354 [mwifiex]
mwifiex_process_sta_rx_packet+0x204/0x26c [mwifiex]
mwifiex_handle_rx_packet+0x15c/0x16c [mwifiex]
mwifiex_rx_work_queue+0x104/0x134 [mwifiex]
worker_thread+0x4cc/0x72c
kthread+0x134/0x13c
ret_from_fork+0x10/0x18

This was clearly not tested well at all. I simply performed 'wget' in a
loop and it fell over within a few seconds.

Fixes: 5188d5453bc9 ("mwifiex: restructure rx_reorder_tbl_lock usage")
Cc: <stable@vger.kernel.org>
Cc: Ganapathi Bhat <gbhat@marvell.com>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

mwifiex: restructure rx_reorder_tbl_lock usage

Driver must ensure that whenever it holds a pointer to the list
entry mwifiex_rx_reorder_tbl, it must protect the same with
rx_reorder_tbl_lock. At present there are many places where
driver does not ensure this. To cover all cases, spinlocks in
below funcions are moved out and made sure that the caller will
hold the spinlock:
mwifiex_11n_dispatch_pkt_until_start_win()
mwifiex_11n_scan_and_dispatch()
mwifiex_del_rx_reorder_entry()
mwifiex_11n_get_rx_reorder_tbl()
mwifiex_11n_find_last_seq_num()

Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

mwifiex: remove warnings in mwifiex_cmd_append_11n_tlv()

Fix the following sparse warning in mwifiex_cmd_append_11n_tlv:

drivers/net/wireless/marvell/mwifiex/11n.c:358:65: warning: invalid assignment: &=
drivers/net/wireless/marvell/mwifiex/11n.c:358:65: left side has type restricted __le16
drivers/net/wireless/marvell/mwifiex/11n.c:358:65: right side has type int
drivers/net/wireless/marvell/mwifiex/11n.c:360:65: warning: invalid assignment: &=
drivers/net/wireless/marvell/mwifiex/11n.c:360:65: left side has type restricted __le16
drivers/net/wireless/marvell/mwifiex/11n.c:360:65: right side has type int
drivers/net/wireless/marvell/mwifiex/11n.c:366:65: warning: invalid assignment: &=
drivers/net/wireless/marvell/mwifiex/11n.c:366:65: left side has type restricted __le16
drivers/net/wireless/marvell/mwifiex/11n.c:366:65: right side has type int
drivers/net/wireless/marvell/mwifiex/11n.c:368:65: warning: invalid assignment: &=
drivers/net/wireless/marvell/mwifiex/11n.c:368:65: left side has type restricted __le16
drivers/net/wireless/marvell/mwifiex/11n.c:368:65: right side has type int

Fixes: 77423fa73927 ("mwifiex: fix incorrect ht capability problem")
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

mwifiex: fix incorrect ht capability problem

IEEE80211_CHAN_NO_HT40PLUS and IEEE80211_CHAN_NO_HT40PLUS channel
flags tell if HT40 operation is allowed on a channel or not.

This patch ensures ht_capability information is modified
accordingly so that we don't end up creating a HT40 connection
when it's not allowed for current regulatory domain.

Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

mwifiex: kill useless list_empty checks

There's absolutely no reason to check to see if a list is empty
before iterating through it. It's just like writing code like
this:

if (count != 0) {
for (i = 0; i < count; i++) {
...
}
}

The loop will already be avoided if "count == 0" so there was no
reason to check.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

mwifiex: make addba request command clean

uninitilized variable, such as .add_req_result might be magic stack
value. Initialize the structure to make it clean.

Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

mwifiex: Add locking to mwifiex_11n_delba

The mwifiex_11n_delba() function walked the rx_reorder_tbl_ptr without
holding the lock, which was an obvious violation.

Grab the lock.

NOTE: we hold the lock while calling mwifiex_send_delba(). There's also
several callers in 11n_rxreorder.c that hold the lock and the comments
in the struct sound just like very other list/lock pair -- as if the
lock should definitely be help for all operations like this.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

mwifiex: Don't release tx_ba_stream_tbl_lock while iterating

Despite the macro list_for_each_entry_safe() having the word "safe" in
the name, it's still not actually safe to release the list spinlock
while iterating over the list. The "safe" in the macro name actually
only means that it's safe to delete the current entry while iterating
over the list.

Releasing the spinlock while iterating over the list means that someone
else could come in and adjust the list while we don't have the
spinlock. If they do that it can totally mix up our iteration and fully
corrupt the list. Later iterating over a corrupted list while holding a
spinlock and having IRQs off can cause all sorts of hard to debug
problems.

As evidenced by the other call to
mwifiex_11n_delete_tx_ba_stream_tbl_entry() in
mwifiex_11n_delete_all_tx_ba_stream_tbl(), it's actually safe to skip
the spinlock release. Let's do that.

No known problems are fixed by this patch, but it could fix all sorts of
weird problems and it should be very safe.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

mwifiex: move under marvell vendor directory

Part of reorganising wireless drivers directory and Kconfig.

Signed-off-by: Kalle Valo <kvalo@codeaurora.org>