summaryrefslogtreecommitdiffstats
path: root/drivers/net/wireless/marvell
AgeCommit message (Collapse)AuthorFilesLines
2019-05-21treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 20Thomas Gleixner1-14/+1
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>
2019-05-21treewide: Add SPDX license identifier - Makefile/KconfigThomas Gleixner6-0/+6
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>
2019-05-21treewide: Add SPDX license identifier for more missed filesThomas Gleixner2-0/+2
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>
2019-05-21treewide: Add SPDX license identifier for missed filesThomas Gleixner4-0/+4
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>
2019-05-05Merge tag 'wireless-drivers-next-for-davem-2019-05-03' of ↵David S. Miller8-25/+107
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>
2019-05-02Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller1-1/+1
Three trivial overlapping conflicts. Signed-off-by: David S. Miller <davem@davemloft.net>
2019-04-27netlink: make validation more configurable for future strictnessJohannes Berg1-2/+2
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>
2019-04-26mwl8k: move spin_lock_bh to spin_lock in taskletJeff Xie1-2/+2
It is unnecessary to call spin_lock_bh in a tasklet. Signed-off-by: Jeff Xie <chongguiguzi@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-25mwifiex: fix spelling mistake "capabilties" -> "capabilities"Colin Ian King2-10/+10
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>
2019-04-25mwifiex: add support for SD8987 chipsetTamás Szűcs3-2/+76
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>
2019-04-25mwl8k: Fix rate_idx underflowPetr Štetiar1-4/+9
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: 854783444bab ("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>
2019-04-25mwl8k: fix error handling in mwl8k_post_cmd()Alexey Khoroshilov1-2/+5
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>
2019-04-25mwifiex: prevent an array overflowDan Carpenter1-0/+3
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: cbf6e05527a7 ("mwifiex: add rx histogram statistics support") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-25mwifiex: use struct_size() in kzalloc()Gustavo A. R. Silva1-5/+2
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>
2019-04-25mwifiex: Make resume actually do something useful again on SDIO cardsDouglas Anderson1-1/+1
The commit fc3a2fcaa1ba ("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: fc3a2fcaa1ba ("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>
2019-04-04mwifiex: add a bounds check in mwifiex_process_sta_rx_packet()Dan Carpenter1-1/+2
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>
2019-04-04mwifiex: Fix mem leak in mwifiex_tm_cmdYueHaibing1-1/+5
'hostcmd' is alloced by kzalloc, should be freed before leaving from the error handling cases, otherwise it will cause mem leak. Fixes: 3935ccc14d2c ("mwifiex: add cfg80211 testmode support") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-04net: mwifiex: fix a NULL pointer dereferenceKangjie Lu1-0/+6
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>
2019-03-20net: remove 'fallback' argument from dev->ndo_select_queue()Paolo Abeni1-2/+1
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>
2019-02-20libertas_tf: get the MAC address before registering the deviceLubomir Rintel1-46/+11
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>
2019-02-20libertas_tf: don't defer firmware loading until start()Lubomir Rintel3-32/+38
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>
2019-02-20libertas_tf: move hardware callbacks to a separate structureLubomir Rintel4-16/+25
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>
2019-02-19mwifiex: don't advertise IBSS features without FW supportBrian Norris1-3/+7
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: e267e71e68ae ("mwifiex: Disable adhoc feature based on firmware capability") Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-02-19mwifiex: Fix NL80211_TX_POWER_LIMITEDAdrian Bunk3-6/+19
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>
2019-02-19libertas_tf: remove set but not used variable 'flags'YueHaibing1-2/+0
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>
2019-02-19libertas_tf: fix signal reportingLubomir Rintel1-1/+2
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>
2019-02-19libertas_tf: move the banner to a more appropriate placeLubomir Rintel1-1/+1
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>
2019-02-19libertas_tf: don't set URB_ZERO_PACKET on IN USB transferLubomir Rintel1-2/+0
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 6528d8804780 ("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>
2019-02-19libertas_tf: lower the debug level of command traceLubomir Rintel1-4/+3
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>
2019-02-08mwifiex: don't print error message on coex eventStefan Agner1-1/+1
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>
2019-02-01mwifiex: no need to check return value of debugfs_create functionsGreg Kroah-Hartman1-3/+2
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>
2019-02-01libertas: no need to check return value of debugfs_create functionsGreg Kroah-Hartman1-6/+0
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>
2019-02-01libertas: fix indentation issueColin Ian King1-1/+1
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>
2019-02-01mwifiex: add support for sd8977 chipsetHemantkumar Suthar3-1/+76
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>
2019-02-01libertas: add checks for the return value of sysfs_create_groupKangjie Lu1-0/+5
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>
2018-12-20Merge tag 'wireless-drivers-next-for-davem-2018-12-20' of ↵David S. Miller4-38/+69
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>
2018-12-20Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller3-53/+51
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>
2018-12-13mwifiex: add NL80211_STA_INFO_RX_BITRATE supportBrian Norris2-5/+34
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>
2018-12-13mwifiex: refactor mwifiex_parse_htinfo() for reuseBrian Norris1-17/+19
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>
2018-12-13mwifiex: debugfs: correct histogram spacing, formattingBrian Norris1-8/+6
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>
2018-12-13mwifiex: fix potential NULL dereference and use after freePan Bian1-8/+10
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>
2018-12-13Revert "mwifiex: restructure rx_reorder_tbl_lock usage"Brian Norris3-53/+51
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>
2018-11-06mwifiex: Mark expected switch fall-throughGustavo A. R. Silva1-0/+1
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>
2018-11-06libertas: remove set but not used variable 'int_type'YueHaibing1-3/+1
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 d2b21f191753 ("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>
2018-10-13libertas: return errno from lbs_add_card()Lubomir Rintel5-14/+20
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>
2018-10-13libertas: don't set URB_ZERO_PACKET on IN USB transferLubomir Rintel1-2/+0
The USB core gets rightfully upset: usb 1-1: BOGUS urb flags, 240 --> 200 WARNING: CPU: 0 PID: 60 at drivers/usb/core/urb.c:503 usb_submit_urb+0x2f8/0x3ed Modules linked in: CPU: 0 PID: 60 Comm: kworker/0:3 Not tainted 4.19.0-rc6-00319-g5206d00a45c7 #39 Hardware name: OLPC XO/XO, BIOS OLPC Ver 1.00.01 06/11/2014 Workqueue: events request_firmware_work_func EIP: usb_submit_urb+0x2f8/0x3ed Code: 75 06 8b 8f 80 00 00 00 8d 47 78 89 4d e4 89 55 e8 e8 35 1c f6 ff 8b 55 e8 56 52 8b 4d e4 51 50 68 e3 ce c7 c0 e8 ed 18 c6 ff <0f> 0b 83 c4 14 80 7d ef 01 74 0a 80 7d ef 03 0f 85 b8 00 00 00 8b EAX: 00000025 EBX: ce7d4980 ECX: 00000000 EDX: 00000001 ESI: 00000200 EDI: ce7d8800 EBP: ce7f5ea8 ESP: ce7f5e70 DS: 007b ES: 007b FS: 0000 GS: 00e0 SS: 0068 EFLAGS: 00210292 CR0: 80050033 CR2: 00000000 CR3: 00e80000 CR4: 00000090 Call Trace: ? if_usb_fw_timeo+0x64/0x64 __if_usb_submit_rx_urb+0x85/0xe6 ? if_usb_fw_timeo+0x64/0x64 if_usb_submit_rx_urb_fwload+0xd/0xf if_usb_prog_firmware+0xc0/0x3db ? _request_firmware+0x54/0x47b ? _request_firmware+0x89/0x47b ? if_usb_probe+0x412/0x412 lbs_fw_loaded+0x55/0xa6 ? debug_smp_processor_id+0x12/0x14 helper_firmware_cb+0x3c/0x3f request_firmware_work_func+0x37/0x6f process_one_work+0x164/0x25a worker_thread+0x1c4/0x284 kthread+0xec/0xf1 ? cancel_delayed_work_sync+0xf/0xf ? kthread_create_on_node+0x1a/0x1a ret_from_fork+0x2e/0x38 ---[ end trace 3ef1e3b2dd53852f ]--- Cc: stable@vger.kernel.org Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-10-12Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller1-0/+4
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>
2018-10-10libertas: call into generic suspend code before turning off powerDaniel Mack1-0/+4
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: 7444a8092906 ("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>
2018-08-31mwifex: free rx_cmd skb in suspended stateGanapathi Bhat1-0/+6
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>
2018-08-31mwifiex: do no submit URB in suspended stateGanapathi Bhat1-0/+7
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>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-20 02:23:08 +0000