First set of fixes for 5.2. Most important here are buffer overflow
fixes for mwifiex.
rtw88
* fix out of bounds compiler warning
* fix rssi handling to get 4x more throughput
* avoid circular locking
rsi
* fix unitilised data warning, these are hopefully the last ones so
that the warning can be enabled by default
mwifiex
* fix buffer overflows
iwlwifi
* remove not used debugfs file
* various fixes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJc+iptAAoJEG4XJFUm622b+cQH/R/k3d55ldIADljn8P1N2JEb
Ogc5weW2DkUgfWdeKpJ1rp7JLaRPypmY4GipA7930SEEk8Ac46WShErH/6TLxEZD
1TGDV/qTtb4QJAZzdd/bs1J8IwaCUK1BolJfcpe5cdE/4/owe2pxiYbvFxAUCGRD
IRK/FJ/ohiv6SB1zUc4ATQ0HWI2OQjiiA4O6WctUSPdHHME7u4/7/MfhD2JBvjBW
454uLf8g2QhMWPdSw/PIXcND+FwgfrS7gCO7pZz4FUy7y6062LLaM+wcgmBxEN9t
SfaH1Ur14Hb0nw4QwYAvY2loJk15iowm7jvuAfqZP9vfpxdt4LYw4KrV/Y7FU8E=
=N7kc
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-for-davem-2019-06-07' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
Kalle Valo says:
====================
wireless-drivers fixes for 5.2
First set of fixes for 5.2. Most important here are buffer overflow
fixes for mwifiex.
rtw88
* fix out of bounds compiler warning
* fix rssi handling to get 4x more throughput
* avoid circular locking
rsi
* fix unitilised data warning, these are hopefully the last ones so
that the warning can be enabled by default
mwifiex
* fix buffer overflows
iwlwifi
* remove not used debugfs file
* various fixes
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Some ISDN files that got removed in net-next had some changes
done in mainline, take the removals.
Signed-off-by: David S. Miller <davem@davemloft.net>
ifa_list is protected by rcu, yet code doesn't reflect this.
Add the __rcu annotations and fix up all places that are now reported by
sparse.
I've done this in the same commit to not add intermediate patches that
result in new warnings.
Reported-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
A few places in mwifiex_uap_parse_tail_ies() perform memcpy()
unconditionally, which may lead to either buffer overflow or read over
boundary.
This patch addresses the issues by checking the read size and the
destination size at each place more properly. Along with the fixes,
the patch cleans up the code slightly by introducing a temporary
variable for the token size, and unifies the error path with the
standard goto statement.
Reported-by: huangwen <huangwen@venustech.com.cn>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option any later version
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-or-later
has been chosen to replace the boilerplate/reference in 3029 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Allison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently mwifiex_update_bss_desc_with_ie() implicitly assumes that
the source descriptor entries contain the enough size for each type
and performs copying without checking the source size. This may lead
to read over boundary.
Fix this by putting the source size check in appropriate places.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
mwifiex_update_bss_desc_with_ie() calls memcpy() unconditionally in
a couple places without checking the destination size. Since the
source is given from user-space, this may trigger a heap buffer
overflow.
Fix it by putting the length check before performing memcpy().
This fix addresses CVE-2019-3846.
Reported-by: huangwen <huangwen@venustech.com.cn>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
There is are two spelling mistakes in lbtf_deb_usb2 messages, fix these.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option any later version this program is distributed in the
hope that it will be useful but without any warranty without even
the implied warranty of merchantability or fitness for a particular
purpose see the gnu general public license for more details you
should have received a copy of the gnu general public license along
with this program see the file copying if not write to the free
software foundation inc 51 franklin steet fifth floor boston ma
02110 1301 usa
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-or-later
has been chosen to replace the boilerplate/reference in 41 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Jilayne Lovejoy <opensource@jilayne.com>
Reviewed-by: Steve Winslow <swinslow@gmail.com>
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Allison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190519154042.524645346@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add SPDX license identifiers to all Make/Kconfig files which:
- Have no license information of any form
These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:
GPL-2.0-only
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add SPDX license identifiers to all files which:
- Have no license information of any form
- Have MODULE_LICENCE("GPL*") inside which was used in the initial
scan/conversion to ignore the file
These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:
GPL-2.0-only
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add SPDX license identifiers to all files which:
- Have no license information of any form
- Have EXPORT_.*_SYMBOL_GPL inside which was used in the
initial scan/conversion to ignore the file
These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:
GPL-2.0-only
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Most likely the last patchset of new feature for 5.2, and this time we
have quite a lot of new features. Most obvious being rtw88 from
Realtek which supports RTL8822BE and RTL8822CE 802.11ac devices. We
have also new hardware support for existing drivers and improvements.
There's one conflict in iwlwifi, my example conflict resolution below.
Major changes:
iwlwifi
* bump the 20000-series FW API version
* work on new hardware continues
* RTT confidence indication support for Fine Timing Measurement (FTM)
* an improvement in HE (802.11ax) rate-scaling
* add command version parsing from the fimware TLVs
* add support for a new WoWLAN patterns firmware API
rsi
* add support for rs9116
mwifiex
* add support for SD8987
brcmfmac
* add quirk for ACEPC T8 and T11 mini PCs
rt2x00
* add RT3883 support
qtnfmac
* fix debugfs interface to support multiple cards
rtw88
* new driver
mt76
* share more code across drivers
* add support for MT7615 chipset
* rework DMA API
* tx/rx performance optimizations
* use NAPI for tx cleanup on mt76x02
* AP mode support for USB devices
* USB stability fixes
* tx power handling fixes for 76x2
* endian fixes
Conflicts:
There's a trivial conflict in
drivers/net/wireless/intel/iwlwifi/fw/file.h, just leave
IWL_UCODE_TLV_FW_FSEQ_VERSION to the file. 'git diff' output should be
just empty:
diff --cc drivers/net/wireless/intel/iwlwifi/fw/file.h
index cd622af90077,b0671e16e1ce..000000000000
--- a/drivers/net/wireless/intel/iwlwifi/fw/file.h
+++ b/drivers/net/wireless/intel/iwlwifi/fw/file.h
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJczDAZAAoJEG4XJFUm622blLgH/jdBKEq9i1m5dtLi48u4sgPV
NsnPhR5XQjpbYpmvgPslKLxWzZq6A0P+lo9QqTXkP/QRyJLu7RnoY1c2wVsQbWaK
VTXc0cROzWt0ihAt8Mc/rEsZpISVnQ9mJbTd/kSJM9WlDeIg0jcJvnEAdQiEmM5t
2t+zZ5CupUXYbGE3zWHL1GSjBD9f0v7zyrNxYNGfvqhDEXhTFWAmVuRtfoAVlRU+
dt1HMv+qdxgoF6Uvaw/kgY09mDvdrfy2EVL0q7S3TKceute60SWf7de2sToI/rMQ
snUnVqTIIUnWPl6g+C3Bp2TbdZhy6XCSRsMFOVa2i1Lt+z1qe3dTr3hjxTQWRhE=
=uLaP
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-next-for-davem-2019-05-03' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:
====================
wireless-drivers-next patches for 5.2
Most likely the last patchset of new feature for 5.2, and this time we
have quite a lot of new features. Most obvious being rtw88 from
Realtek which supports RTL8822BE and RTL8822CE 802.11ac devices. We
have also new hardware support for existing drivers and improvements.
There's one conflict in iwlwifi, my example conflict resolution below.
Major changes:
iwlwifi
* bump the 20000-series FW API version
* work on new hardware continues
* RTT confidence indication support for Fine Timing Measurement (FTM)
* an improvement in HE (802.11ax) rate-scaling
* add command version parsing from the fimware TLVs
* add support for a new WoWLAN patterns firmware API
rsi
* add support for rs9116
mwifiex
* add support for SD8987
brcmfmac
* add quirk for ACEPC T8 and T11 mini PCs
rt2x00
* add RT3883 support
qtnfmac
* fix debugfs interface to support multiple cards
rtw88
* new driver
mt76
* share more code across drivers
* add support for MT7615 chipset
* rework DMA API
* tx/rx performance optimizations
* use NAPI for tx cleanup on mt76x02
* AP mode support for USB devices
* USB stability fixes
* tx power handling fixes for 76x2
* endian fixes
Conflicts:
There's a trivial conflict in
drivers/net/wireless/intel/iwlwifi/fw/file.h, just leave
IWL_UCODE_TLV_FW_FSEQ_VERSION to the file. 'git diff' output should be
just empty:
diff --cc drivers/net/wireless/intel/iwlwifi/fw/file.h
index cd622af90077,b0671e16e1ce..000000000000
--- a/drivers/net/wireless/intel/iwlwifi/fw/file.h
+++ b/drivers/net/wireless/intel/iwlwifi/fw/file.h
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
We currently have two levels of strict validation:
1) liberal (default)
- undefined (type >= max) & NLA_UNSPEC attributes accepted
- attribute length >= expected accepted
- garbage at end of message accepted
2) strict (opt-in)
- NLA_UNSPEC attributes accepted
- attribute length >= expected accepted
Split out parsing strictness into four different options:
* TRAILING - check that there's no trailing data after parsing
attributes (in message or nested)
* MAXTYPE - reject attrs > max known type
* UNSPEC - reject attributes with NLA_UNSPEC policy entries
* STRICT_ATTRS - strictly validate attribute size
The default for future things should be *everything*.
The current *_strict() is a combination of TRAILING and MAXTYPE,
and is renamed to _deprecated_strict().
The current regular parsing has none of this, and is renamed to
*_parse_deprecated().
Additionally it allows us to selectively set one of the new flags
even on old policies. Notably, the UNSPEC flag could be useful in
this case, since it can be arranged (by filling in the policy) to
not be an incompatible userspace ABI change, but would then going
forward prevent forgetting attribute entries. Similar can apply
to the POLICY flag.
We end up with the following renames:
* nla_parse -> nla_parse_deprecated
* nla_parse_strict -> nla_parse_deprecated_strict
* nlmsg_parse -> nlmsg_parse_deprecated
* nlmsg_parse_strict -> nlmsg_parse_deprecated_strict
* nla_parse_nested -> nla_parse_nested_deprecated
* nla_validate_nested -> nla_validate_nested_deprecated
Using spatch, of course:
@@
expression TB, MAX, HEAD, LEN, POL, EXT;
@@
-nla_parse(TB, MAX, HEAD, LEN, POL, EXT)
+nla_parse_deprecated(TB, MAX, HEAD, LEN, POL, EXT)
@@
expression NLH, HDRLEN, TB, MAX, POL, EXT;
@@
-nlmsg_parse(NLH, HDRLEN, TB, MAX, POL, EXT)
+nlmsg_parse_deprecated(NLH, HDRLEN, TB, MAX, POL, EXT)
@@
expression NLH, HDRLEN, TB, MAX, POL, EXT;
@@
-nlmsg_parse_strict(NLH, HDRLEN, TB, MAX, POL, EXT)
+nlmsg_parse_deprecated_strict(NLH, HDRLEN, TB, MAX, POL, EXT)
@@
expression TB, MAX, NLA, POL, EXT;
@@
-nla_parse_nested(TB, MAX, NLA, POL, EXT)
+nla_parse_nested_deprecated(TB, MAX, NLA, POL, EXT)
@@
expression START, MAX, POL, EXT;
@@
-nla_validate_nested(START, MAX, POL, EXT)
+nla_validate_nested_deprecated(START, MAX, POL, EXT)
@@
expression NLH, HDRLEN, MAX, POL, EXT;
@@
-nlmsg_validate(NLH, HDRLEN, MAX, POL, EXT)
+nlmsg_validate_deprecated(NLH, HDRLEN, MAX, POL, EXT)
For this patch, don't actually add the strict, non-renamed versions
yet so that it breaks compile if I get it wrong.
Also, while at it, make nla_validate and nla_parse go down to a
common __nla_validate_parse() function to avoid code duplication.
Ultimately, this allows us to have very strict validation for every
new caller of nla_parse()/nlmsg_parse() etc as re-introduced in the
next patch, while existing things will continue to work as is.
In effect then, this adds fully strict validation for any new command.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
There various spelling mistakes in function names and in message
text. Fix these.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
This patch adds support for Marvell 88W8987 chipset with SDIO interface.
Register offsets and supported feature flags are updated. The corresponding
firmware image file shall be "mrvl/sd8987_uapsta.bin".
Signed-off-by: Tamás Szűcs <tszucs@protonmail.ch>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
It was reported on OpenWrt bug tracking system[1], that several users
are affected by the endless reboot of their routers if they configure
5GHz interface with channel 44 or 48.
The reboot loop is caused by the following excessive number of WARN_ON
messages:
WARNING: CPU: 0 PID: 0 at backports-4.19.23-1/net/mac80211/rx.c:4516
ieee80211_rx_napi+0x1fc/0xa54 [mac80211]
as the messages are being correctly emitted by the following guard:
case RX_ENC_LEGACY:
if (WARN_ON(status->rate_idx >= sband->n_bitrates))
as the rate_idx is in this case erroneously set to 251 (0xfb). This fix
simply converts previously used magic number to proper constant and
guards against substraction which is leading to the currently observed
underflow.
1. https://bugs.openwrt.org/index.php?do=details&task_id=2218
Fixes: 854783444b ("mwl8k: properly set receive status rate index on 5 GHz receive")
Cc: <stable@vger.kernel.org>
Tested-by: Eubert Bao <bunnier@gmail.com>
Reported-by: Eubert Bao <bunnier@gmail.com>
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
If pci_map_single() fails in mwl8k_post_cmd(),
it returns -ENOMEM immediately, while cleanup is required.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The "rate_index" is only used as an index into the phist_data->rx_rate[]
array in the mwifiex_hist_data_set() function. That array has
MWIFIEX_MAX_AC_RX_RATES (74) elements and it's used to generate some
debugfs information. The "rate_index" variable comes from the network
skb->data[] and it is a u8 so it's in the 0-255 range. We need to cap
it to prevent an array overflow.
Fixes: cbf6e05527 ("mwifiex: add rx histogram statistics support")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
struct boo entry[];
};
size = sizeof(struct foo) + count * sizeof(struct boo);
instance = kzalloc(size, GFP_KERNEL)
Instead of leaving these open-coded and prone to type mistakes, we can
now use the new struct_size() helper:
instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL)
Notice that, in this case, variable regd_size is not necessary,
hence it is removed.
This code was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The commit fc3a2fcaa1 ("mwifiex: use atomic bitops to represent
adapter status variables") had a fairly straightforward bug in it. It
contained this bit of diff:
- if (!adapter->is_suspended) {
+ if (test_bit(MWIFIEX_IS_SUSPENDED, &adapter->work_flags)) {
As you can see the patch missed the "!" when converting to the atomic
bitops. This meant that the resume hasn't done anything at all since
that commit landed and suspend/resume for mwifiex SDIO cards has been
totally broken.
After fixing this mwifiex suspend/resume appears to work again, at
least with the simple testing I've done.
Fixes: fc3a2fcaa1 ("mwifiex: use atomic bitops to represent adapter status variables")
Cc: <stable@vger.kernel.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Smatch complains that "local_rx_pd->priority" can't be trusted because
it comes from skb->data and it can go up to 255 instead of being capped
in the 0-7 range. A few lines earlier, on the other side of the if
statement, we cap priority so it seems harmless to add a bounds check
here as well.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
'hostcmd' is alloced by kzalloc, should be freed before
leaving from the error handling cases, otherwise it will
cause mem leak.
Fixes: 3935ccc14d ("mwifiex: add cfg80211 testmode support")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
In case dev_alloc_skb fails, the fix returns -ENOMEM to avoid
NULL pointer dereference.
Signed-off-by: Kangjie Lu <kjlu@umn.edu>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
After the previous patch, all the callers of ndo_select_queue()
provide as a 'fallback' argument netdev_pick_tx.
The only exceptions are nested calls to ndo_select_queue(),
which pass down the 'fallback' available in the current scope
- still netdev_pick_tx.
We can drop such argument and replace fallback() invocation with
netdev_pick_tx(). This avoids an indirect call per xmit packet
in some scenarios (TCP syn, UDP unconnected, XDP generic, pktgen)
with device drivers implementing such ndo. It also clean the code
a bit.
Tested with ixgbe and CONFIG_FCOE=m
With pktgen using queue xmit:
threads vanilla patched
(kpps) (kpps)
1 2334 2428
2 4166 4278
4 7895 8100
v1 -> v2:
- rebased after helper's name change
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The start() callback is too late for this: NetworkManager would already
have seen the hardware, thinking 00:00:00:00:00:00 is its permanent
address.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Reviewed-by: Steve deRosier <derosier@cal-sierra.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
In order to be able to get a MAC address before we register the device
with ieee80211 we'll need to load the firmware way earlier.
There seems to be one problem with this: the device seems to start
with radio enabled and starts sending in frames right after the firmware
load finishes. Disable the radio as soon as possible.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Reviewed-by: Steve deRosier <derosier@cal-sierra.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
We'll need to talk to the firmware to get a hardware address before
device is registered with ieee80211 subsystem at the end of
lbtf_add_card(). Hooking the callbacks after that is too late.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
As it is, doing something like
# iw phy phy0 interface add foobar type ibss
on a firmware that doesn't have ad-hoc support just yields failures of
HostCmd_CMD_SET_BSS_MODE, which happened to return a '-1' error code
(-EPERM? not really right...) and sometimes may even crash the firmware
along the way.
Let's parse the firmware capability flag while registering the wiphy, so
we don't allow attempting IBSS at all, and we get a proper -EOPNOTSUPP
from nl80211 instead.
Fixes: e267e71e68 ("mwifiex: Disable adhoc feature based on firmware capability")
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
NL80211_TX_POWER_LIMITED was treated as NL80211_TX_POWER_AUTOMATIC,
which is the opposite of what should happen and can cause nasty
regulatory problems.
if/else converted to a switch without default to make gcc warn
on unhandled enum values.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/marvell/libertas_tf/main.c: In function 'lbtf_rx':
drivers/net/wireless/marvell/libertas_tf/main.c:554:15: warning:
variable 'flags' set but not used [-Wunused-but-set-variable]
It never used and can be removed.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Steve deRosier <derosier@cal-sierra.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Instead of exposing the signal-to-noise ration, calculate the actual signal
level taking the noise floor into account.
Also, flip the SIGNAL_DBM bit on, so that mac80211 exposes the signal
level along with the station info in scan results. This fills
NetworkManager's "nmcli d wifi output" output with colors, bars and joy.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Reviewed-by: Steve deRosier <derosier@cal-sierra.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Also, turn it to a dev_info() to make checkpatch.pl happy.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Reviewed-by: Steve deRosier <derosier@cal-sierra.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
It doesn't make sense and the USB core warns on each submit of such
URB, easily flooding the message buffer with tracebacks.
Analogous issue was fixed in regular libertas driver in commit 6528d88047
("libertas: don't set URB_ZERO_PACKET on IN USB transfer").
Cc: stable@vger.kernel.org
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Reviewed-by: Steve deRosier <derosier@cal-sierra.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Logging each and every command response is way too much for INFO level.
Silence this, unless CONFIG_LIBERTAS_THINFIRM_DEBUG has been enabled.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Reviewed-by: Steve deRosier <derosier@cal-sierra.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The BT coex event is not an error condition. Don't print an error
message in this case. The same even in sta_event.c prints a
message using the debug level already.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Amitkumar Karwar <amitkarwar@gmail.com>
Cc: Nishant Sarmukadam <nishants@marvell.com>
Cc: Ganapathi Bhat <gbhat@marvell.com>
Cc: Xinming Hu <huxinming820@gmail.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: linux-wireless@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: libertas-dev@lists.infradead.org
Cc: linux-wireless@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
There is a statement that is incorrectly indented, fix it.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
This patch adds support for 8977 chipset to mwifiex with SDIO
interface. Register offsets and supported feature flags are
updated. Firmware image used will be mrvl/sd8977_uapsta.bin.
Signed-off-by: Hemantkumar Suthar <shemant@marvell.com>
Signed-off-by: Rakesh Parmar <rakeshp@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
sysfs_create_group() could fail. The fix checkes its return values
and issue error messages if it fails.
Signed-off-by: Kangjie Lu <kjlu@umn.edu>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Last set of patches for 4.21. mt76 is still in very active development
and having some refactoring as well as new features. But also other
drivers got few new features and fixes.
Major changes:
ath10k
* add amsdu support for QCA6174 monitor mode
* report tx rate using the new ieee80211_tx_rate_update() API
* wcn3990 support is not experimental anymore
iwlwifi
* support for FW version 43 for 9000 and 22000 series
brcmfmac
* add support for CYW43012 SDIO chipset
* add the raw 4354 PCIe device ID for unprogrammed Cypress boards
mwifiex
* add NL80211_STA_INFO_RX_BITRATE support
mt76
* use the same firmware for mt76x2e and mt76x2u
* mt76x0e survey support
* more unification between mt76x2 and mt76x0
* mt76x0e AP mode support
* mt76x0e DFS support
* rework and fix tx status handling for mt76x0 and mt76x2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJcG9TEAAoJEG4XJFUm622byW8H/1vMVJhXwgIZbHeoUKNa47Yp
Z7Jv5vW8IGXu+lp7DyoedDCbq4+lskNSlDV1DmysNChLgDnApU/3oCd/jH8EiGPV
JAFUHb85HuVLTTpPpNHtnYz3IzL7r098TNVxOU0VD+xILM0Mf0aCeXztgmFWpGaY
/rfHkId8oKUezIjdu6Dc96mqITrT6WRNtnOMfjr6dZPjClRTS44Hyz3Ga3rXABBL
/n8BCkl0GpKGrL3mBy2CCR5mVY8zfxMB4Aj2zx7bccZ8i2i2QjrGlXCHyB6ImNrR
lv4L1fUVXZWVdeOe8EbpftY7zEsPrX+XNm6h1kckdB7UyuBROpQLsVb+yxlLh9g=
=mhAw
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-next-for-davem-2018-12-20' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:
====================
wireless-drivers-next patches for 4.21
Last set of patches for 4.21. mt76 is still in very active development
and having some refactoring as well as new features. But also other
drivers got few new features and fixes.
Major changes:
ath10k
* add amsdu support for QCA6174 monitor mode
* report tx rate using the new ieee80211_tx_rate_update() API
* wcn3990 support is not experimental anymore
iwlwifi
* support for FW version 43 for 9000 and 22000 series
brcmfmac
* add support for CYW43012 SDIO chipset
* add the raw 4354 PCIe device ID for unprogrammed Cypress boards
mwifiex
* add NL80211_STA_INFO_RX_BITRATE support
mt76
* use the same firmware for mt76x2e and mt76x2u
* mt76x0e survey support
* more unification between mt76x2 and mt76x0
* mt76x0e AP mode support
* mt76x0e DFS support
* rework and fix tx status handling for mt76x0 and mt76x2
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Lots of conflicts, by happily all cases of overlapping
changes, parallel adds, things of that nature.
Thanks to Stephen Rothwell, Saeed Mahameed, and others
for their guidance in these resolutions.
Signed-off-by: David S. Miller <davem@davemloft.net>
Comparing the existing TX_BITRATE parsing code (in
mwifiex_parse_htinfo()) with the RX bitrate histograms in debugfs.c, it
appears that the rxpd_rate and rxpd_htinfo fields have the same format.
At least, they give reasonable results when I parse them this way.
So this patch adds support for RX_BITRATE to our station info dump.
Along the way, I add legacy bitrate parsing into the same function,
using the debugfs code (mwifiex_histogram_read() and
mwifiex_adjust_data_rate()) as reference.
Additionally, to satisfy the requirements of
NL80211_STA_INFO_RX_BITRATE, I skip logging the bitrate of multicast
packets. This shouldn't add a lot of overhead to the RX path, as there
are already several similar 802.3 header checks in this same codepath.
We can also bias the branch behavior to favor unicast, as that's the
common performance-sensitive case.
I'd consider this support somewhat experimental, as I have zero
documentation from Marvell. But the existing driver code gives me good
reason to think this is correct.
I've tested this on a few different 802.11{a,b,g,n,ac} networks, and the
reported bitrates look good to me.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
This function converts some firmware-specific parameters into cfg80211
'rate_info' structures. It currently assumes it's dealing only with TX
bitrate, but the RX bitrate looks to be the same, so refactor this
function to be reusable.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Currently, snippets of this file look like:
rx rates (in Mbps): 0=1M 1=2M2=5.5M 3=11M 4=6M 5=9M 6=12M
7=18M 8=24M 9=36M 10=48M 11=54M12-27=MCS0-15(BW20) 28-43=MCS0-15(BW40)
44-53=MCS0-9(VHT:BW20)54-63=MCS0-9(VHT:BW40)64-73=MCS0-9(VHT:BW80)
...
noise_flr[--96dBm] = 22
noise_flr[--95dBm] = 149
noise_flr[--94dBm] = 9
noise_flr[--93dBm] = 2
We're missing some spaces, and we're adding a minus sign ('-') on values
that are already negative signed integers.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
There are two defects: (1) passing a NULL bss to
mwifiex_save_hidden_ssid_channels will result in NULL dereference,
(2) using bss after dropping the reference to it via cfg80211_put_bss.
To fix them, the patch moves the buggy code to the branch that bss is
not NULL and puts it before cfg80211_put_bss.
Signed-off-by: Pan Bian <bianpan2016@163.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
This reverts commit 5188d5453b, 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: 5188d5453b ("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>
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/marvell/libertas/if_spi.c: In function 'if_spi_h2c':
drivers/net/wireless/marvell/libertas/if_spi.c:799:6: warning:
variable 'int_type' set but not used [-Wunused-but-set-variable]
It never used since introduction in
commit d2b21f1917 ("libertas: if_spi, driver for libertas GSPI devices")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Tested-by: Lubomir Rintel <lkundrak@v3.sk>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
This makes the error handling somewhat cleaner -- lbs_add_card() does no
logner throw away the errno and lets its callers propagate it.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Conflicts were easy to resolve using immediate context mostly,
except the cls_u32.c one where I simply too the entire HEAD
chunk.
Signed-off-by: David S. Miller <davem@davemloft.net>
When powering down a SDIO connected card during suspend, make sure to call
into the generic lbs_suspend() function before pulling the plug. This will
make sure the card is successfully deregistered from the system to avoid
communication to the card starving out.
Fixes: 7444a80929 ("libertas: fix suspend and resume for SDIO connected cards")
Signed-off-by: Daniel Mack <daniel@zonque.org>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
USB suspend handler will kill the presubmitted rx_cmd URB. This
triggers a call to the corresponding URB complete handler, which
will free the rx_cmd skb, associated with rx_cmd URB. Due to a
possible race betwen suspend handler and main thread, depicted in
'commit bfcacac6c84b ("mwifiex: do no submit URB in suspended
state")', it is possible that the rx_cmd skb will fail to get
freed. This causes a memory leak, since the resume handler will
always allocate a new rx_cmd skb.
To fix this, free the rx_cmd skb in mwifiex_usb_submit_rx_urb, if
the device is in suspended state.
Signed-off-by: Vidya Dharmaraju <vidyad@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
There is a possible race between USB suspend and main thread:
1. After processing the command response, main thread will submit
rx_cmd URB back so as to process next command response, by
calling mwifiex_usb_submit_rx_urb.
2. During USB suspend, the suspend handler will check if rx_cmd
URB is pending(submitted) and if true, kill this URB.
There is a possible race between #1 and #2, where rx_cmd URB will
be submitted by main thread(#1) after the suspend handler check
in #2.
To fix this, check if device is already suspended in
mwifiex_usb_submit_rx_urb, in which case do not submit the URB.
Signed-off-by: Vidya Dharmaraju <vidyad@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
If recvlength is less than MESSAGE_HEADER_LEN (4) we would end up
corrupting memory.
Fixes: c305a19a0d ("libertas_tf: usb specific functions")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Mwifiex firmware inserts only Microsoft information element
Allow other vendor specific IEs to pass from userspace
Signed-off-by: Roman Stratiienko <roman.stratiienko@globallogic.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Driver is using boolean variables to maintain vairous status
information of adapter. These status variables are accessed by
multiple threads and there is a possibility of a race. To avoid
this, convert these variables to a set of bitops flags, to be
operated atomically.
Below variables of mwifiex_adapter are converted to bitop flags:
surprise_removed
is_cmd_timedout
is_suspended
is_hs_configured
hs_enabling
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
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>
At present driver spinlock protects iteration of list
rx_reorder_tbl_ptr with rx_reorder_tbl_lock. To protect the
individual items in this list, it uses rx_pkt_lock. But, we can
use a single rx_reorder_tbl_lock for both purposes. This patch
replaces rx_pkt_lock by rx_reorder_tbl_lock.
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The first set of patches for 4.19. Only smaller features and bug
fixes, not really anything major. Also included are changes to
include/linux/bitfield.h, we agreed with Johannes that it makes sense
to apply them via wireless-drivers-next.
Major changes:
ath10k
* support channel 173
* fix spectral scan for QCA9984 and QCA9888 chipsets
ath6kl
* add support for Dell Wireless 1537
ti wlcore
* add support for runtime PM
* enable runtime PM autosuspend support
qtnfmac
* support changing MAC address
* enable source MAC address randomization support
libertas
* fix suspend and resume for SDIO cards
mt76
* add software DFS radar pattern detector for mt76x2 based devices
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJbVgnkAAoJEG4XJFUm622b/DAH/0wmjFQrt1qe/goZ4igZOC5z
TTqPUmv7HO4PbHV6mU5yOFGsRCaGDo1cTyEeoiaYNGH6bQLzzJZeQORkuPQB2q5S
BCwlaET7F2iSmk8hx7eboONyVDm5v2+g6NMHBoikVFz1wZ13kCVa4sHkokUJKYB9
XNw3B2OiarPv9i37DlY3woMlY+6VMQh8J6GiB9cJSa4Xs+7l1aQCdQRP03SabI71
gLBEsW+bEVZrUdJGB5cZ8c6LmukmRQMDKMTQYUna5ZXeW1IX3ejYcQGHzzCZoKJS
LPUmisz4014r5aBzXIu3ctVn4LnVhMS5ms0EH1A6IX3vx8G9QynqH5lm9VQ1OXI=
=kWW/
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-next-for-davem-2018-07-23' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:
====================
wireless-drivers-next patches for 4.19
The first set of patches for 4.19. Only smaller features and bug
fixes, not really anything major. Also included are changes to
include/linux/bitfield.h, we agreed with Johannes that it makes sense
to apply them via wireless-drivers-next.
Major changes:
ath10k
* support channel 173
* fix spectral scan for QCA9984 and QCA9888 chipsets
ath6kl
* add support for Dell Wireless 1537
ti wlcore
* add support for runtime PM
* enable runtime PM autosuspend support
qtnfmac
* support changing MAC address
* enable source MAC address randomization support
libertas
* fix suspend and resume for SDIO cards
mt76
* add software DFS radar pattern detector for mt76x2 based devices
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch makes it so that instead of passing a void pointer as the
accel_priv we instead pass a net_device pointer as sb_dev. Making this
change allows us to pass the subordinate device through to the fallback
function eventually so that we can keep the actual code in the
ndo_select_queue call as focused on possible on the exception cases.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Prior to commit 573185cc7e ("mmc: core: Invoke sdio func driver's PM
callbacks from the sdio bus"), the MMC core used to call into the power
management functions of SDIO clients itself and removed the card if the
return code was non-zero. IOW, the mmc handled errors gracefully and didn't
upchain them to the pm core.
Since this change, the mmc core relies on generic power management
functions which treat all errors as a reason to cancel the suspend
immediately. This causes suspend attempts to fail when the libertas
driver is loaded.
To fix this, power down the card explicitly in if_sdio_suspend() when we
know we're about to lose power and return success. Also set a flag in these
cases, and power up the card again in if_sdio_resume().
Fixes: 573185cc7e ("mmc: core: Invoke sdio func driver's PM callbacks from the sdio bus")
Cc: <stable@vger.kernel.org>
Signed-off-by: Daniel Mack <daniel@zonque.org>
Reviewed-by: Chris Ball <chris@printf.net>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The USB completion callback does not disable interrupts while acquiring
the lock. We want to remove the local_irq_disable() invocation from
__usb_hcd_giveback_urb() and therefore it is required for the callback
handler to disable the interrupts while acquiring the lock.
The callback may be invoked either in IRQ or BH context depending on the
USB host controller.
Use the _irqsave() variant of the locking primitives.
I am removing the
BUG_ON(!in_interrupt());
check because it serves no purpose. Running the completion callback in
BH context makes in_interrupt() still return true but the interrupts
could be enabled. The important part is that ->driver_lock is acquired
with disabled interrupts which is the case now.
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: libertas-dev@lists.infradead.org
Cc: linux-wireless@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The USB completion callback does not disable interrupts while acquiring
the lock. We want to remove the local_irq_disable() invocation from
__usb_hcd_giveback_urb() and therefore it is required for the callback
handler to disable the interrupts while acquiring the lock.
The callback may be invoked either in IRQ or BH context depending on the
USB host controller.
Use the _irqsave() variant of the locking primitives.
I am removing the
BUG_ON(!in_interrupt());
check because it serves no purpose. Running the completion callback in
BH context makes in_interrupt() still return true but the interrupts
could be enabled. The important part is that ->driver_lock is acquired
with disabled interrupts which is the case now.
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-wireless@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The BIT macro uses unsigned long which some architectures handle as 32 bit
and therefore might cause macro's shift to overflow when used on a value
equals or larger than 32 (NL80211_STA_INFO_RX_DURATION and afterwards).
Since 'filled' member in station_info changed to u64, BIT_ULL macro
should be used with all NL80211_STA_INFO_* attribute types instead of BIT
to prevent future possible bugs when one will use BIT macro for higher
attributes by mistake.
This commit cleans up all usages of BIT macro with the above field
in wireless-drivers by changing it to BIT_ULL instead. In addition, there are
some places which don't use BIT nor BIT_ULL macros so align those as well.
Signed-off-by: Omer Efrat <omer.efrat@tandemg.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Do not chock ethernet header for uap bridge data path,
as it is still needed to send skb to dest station.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Race condition is observed during rmmod of mwifiex_usb:
1. The rmmod thread will call mwifiex_usb_disconnect(), download
SHUTDOWN command and do wait_event_interruptible_timeout(),
waiting for response.
2. The main thread will handle the response and will do a
wake_up_interruptible(), unblocking rmmod thread.
3. On getting unblocked, rmmod thread will make rx_cmd.urb = NULL in
mwifiex_usb_free().
4. The main thread will try to resubmit rx_cmd.urb in
mwifiex_usb_submit_rx_urb(), which is NULL.
To fix this, move mwifiex_usb_free() from mwifiex_usb_disconnect
to mwifiex_unregister_dev(). Function mwifiex_unregister_dev() is
called after flushing the command and RX work queues.
Suggested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
This reverts commit b817047ae7.
We have a better fix for this issue, which will be sent on top
of this revert.
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Active scan is not allowed on radar channel, instead
using passvie scan with more time.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
If firmware does not support embedded supplicant, then it in turn
will not support GT rekey offloading. If this is the case, then
driver must not advertise WOWLAN flags related to GTK rekey and
it must also skip sending the GT_REKEY_OFFLOAD_CFG command.
Signed-off-by: Shrenik Shikhare <shrenik@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Race condition is observed during rmmod of mwifiex_usb:
1. The rmmod thread will call mwifiex_usb_disconnect(), download
SHUTDOWN command and do wait_event_interruptible_timeout(),
waiting for response.
2. The main thread will handle the response and will do a
wake_up_interruptible(), unblocking rmmod thread.
3. On getting unblocked, rmmod thread will make rx_cmd.urb = NULL in
mwifiex_usb_free().
4. The main thread will try to resubmit rx_cmd.urb in
mwifiex_usb_submit_rx_urb(), which is NULL.
To fix, wait for main thread to complete before calling
mwifiex_usb_free().
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
This is a follow-up patch for commit 21c5c83ce8
("mwifiex: support sysfs initiated device coredump").
Let us avoid exporting mwifiex_send_cmd and instead use a utility
function mwifiex_fw_dump_event to achive the work.
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Since commit 3c47d19ff4 ("drivers: base: add coredump driver ops")
it is possible to initiate a device coredump from user-space. This
patch adds support for it adding the .coredump() driver callback.
As there is no longer a need to initiate it through debugfs remove
that code.
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Correct snr/nr/rssi data index to avoid possible buffer underflow.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Since the addition of the TXQ stats to cfg80211, the station_info struct
has grown to be quite large, which results in warnings when allocated on
the stack. Fix the affected places to do dynamic allocations instead.
Fixes: 52539ca89f ("cfg80211: Expose TXQ stats and parameters to userspace")
Reviewed-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
While carrying energy detection(ED) tests, the chip will stop
transmission upon detecting an energy in the connected channel.
As a feedback, driver will stop dequeuing TX packets and due to
which wmm_tx_pending keep incremeting. Once wmm_tx_pending
reaches 100, driver calls netif_tx_stop_queue(). If TX ques is
not restarted within 5(watchdog_timeo) seconds, it will result in
TX timeout.
The ED test is carried out for one minute and the current
threshold of 100 is easily overcome by the traffic, cuasing TX
timeouts. To fix this increase the threshold to 400.
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Nothing that is defined in 11ac.h is referenced in cmdevt.c.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
During changing virtual interface, keep using previous net device
mac address.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
When interface type changed, firmware using a new connction pointer.
We need Re-configure the mac address.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
For user configurated mac address, directly set to firmware with no change.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, but the implementation in this
driver returns an 'int'.
Fix this by returning 'netdev_tx_t' in this driver too.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
If "evt_len" is 1 then we try to memcpy() negative 3 bytes and it would
cause memory corruption.
Fixes: d930faee14 ("mwifiex: add support for Marvell pcie8766 chipset")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Firmware already support hidden ssid and keep ssid length,
Open the capability in driver.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Firmware parse and attach ERP IE from bss configuration,
do not set again from tail IE.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
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: 77423fa739 ("mwifiex: fix incorrect ht capability problem")
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
At present driver gets chan_type by referring to
IEEE80211_HT_PARAM_CHA_SEC_OFFSET, in ASSOC response. Sometimes
AP shows IEEE80211_HT_PARAM_CHA_SEC_OFFSET as above/below in
assoc response, even if the association is done on HT20 channel
only. So, it will be accurate to get econdary channel offset from
firmware.
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
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>
This reverts commit bcc920e8f0.
Drivers gets hardware info and updates ht_cap field of
wiphy->bands during initialization. Once updated during init,
ht_cap must not be modified as it reflects the capability
supported by hardwawre. Above patch tries to modify the ht_cap
field and this results in wrongly advertising capabilities during
association.
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
High bits of antenna number are reserved in hardware spec,
using low 4 bits represent supported antenna.
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Lots of the wireless driver vendor Kconfig symol help text says
"questions about cards." (2 spaces between "about" and "cards")
Besides dropping one of those spaces, it also needs some other word
inserted there. Instead of putting each vendor's name there, I chose
to say "these" cards in all of the Kconfig help text.
Cc: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
