- 29 Nov, 2016 3 commits
-
-
Kirtika Ruchandani authored
Commit 429d90d2 introduced mwifiex_cmd_tdls_oper() which initializes struct mwifiex_sta_node* sta_ptr, but does not use it. Compiling with W=1 gives the following warning, fix it. mwifiex/sta_cmd.c: In function ‘mwifiex_cmd_tdls_oper’: mwifiex/sta_cmd.c:1732:27: warning: variable ‘sta_ptr’ set but not used [-Wunused-but-set-variable] Fixes: 429d90d2 ("mwifiex: add cfg80211 tdls_oper handler support") Cc: Avinash Patil <patila@marvell.com> Signed-off-by: Kirtika Ruchandani <kirtika@google.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Kirtika Ruchandani authored
Commit b5413e6b removed all uses of chan_num in mwifiex_config_scan(). Compiling mwifiex with W=1 gives the following warning, fix it. mwifiex/scan.c: In function ‘mwifiex_config_scan’: mwifiex/scan.c:830:6: warning: variable ‘chan_num’ set but not used [-Wunused-but-set-variable] Fixes: b5413e6b ("mwifiex: increase the number of nodes in command pool") Cc: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kirtika Ruchandani <kirtika@google.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Kirtika Ruchandani authored
Commit bec568ff removed the last remaining usage of struct mwifiex_private* priv in mwifiex_fw_dpc(), by removing the call to mwifiex_del_virtual_intf(). Compiling mwifiex/ with W=1 gives the following warning, fix it. mwifiex/main.c: In function ‘mwifiex_fw_dpc’: mwifiex/main.c:520:26: warning: variable ‘priv’ set but not used [-Wunused-but-set-variable] Fixes: bec568ff ("mwifiex: failure path handling in mwifiex_add_virtual_intf()") Cc: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kirtika Ruchandani <kirtika@google.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
- 28 Nov, 2016 1 commit
-
-
Barry Day authored
Move the dev_info call that attempts to show the rate used before it is set. Signed-off-by: Barry Day <briselec@gmail.com> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Barry Day <briselec@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
- 25 Nov, 2016 15 commits
-
-
Tobias Regnery authored
I get the following UBSAN warning during boot on my laptop: ================================================================================ UBSAN: Undefined behaviour in drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_qmath.c:280:21 index 32 is out of range for type 's16 [32]' CPU: 0 PID: 879 Comm: NetworkManager Not tainted 4.9.0-rc4 #28 Hardware name: LENOVO Lenovo IdeaPad N581/INVALID, BIOS 5ECN96WW(V9.01) 03/14/2013 ffff8800b74a6478 ffffffff828e59d2 0000000041b58ab3 ffffffff8398330c ffffffff828e5920 ffff8800b74a64a0 ffff8800b74a6450 0000000000000020 1ffffffff845848c ffffed0016e94bf1 ffffffffc22c2460 000000006b9c0514 Call Trace: [<ffffffff828e59d2>] dump_stack+0xb2/0x110 [<ffffffff828e5920>] ? _atomic_dec_and_lock+0x150/0x150 [<ffffffff82968c9d>] ubsan_epilogue+0xd/0x4e [<ffffffff82969875>] __ubsan_handle_out_of_bounds+0xfa/0x13e [<ffffffff8296977b>] ? __ubsan_handle_shift_out_of_bounds+0x241/0x241 [<ffffffffc0d48379>] ? bcma_host_pci_read16+0x59/0xa0 [bcma] [<ffffffffc0d48388>] ? bcma_host_pci_read16+0x68/0xa0 [bcma] [<ffffffffc212ad78>] ? read_phy_reg+0xe8/0x180 [brcmsmac] [<ffffffffc2184714>] qm_log10+0x2e4/0x350 [brcmsmac] [<ffffffffc2142eb8>] wlc_phy_init_lcnphy+0x538/0x1f20 [brcmsmac] [<ffffffffc2142980>] ? wlc_lcnphy_periodic_cal+0x5c0/0x5c0 [brcmsmac] [<ffffffffc1ba0c93>] ? ieee80211_open+0xb3/0x110 [mac80211] [<ffffffff82f73a02>] ? sk_busy_loop+0x1e2/0x840 [<ffffffff82f7a6ce>] ? __dev_change_flags+0xae/0x220 ... The report is valid: doing the math in this function, with an input value N=63 the variable s16tableIndex gets a value of 31. This value is used as an index in the array log_table with 32 entries. But the next line is: s16errorApproximation = (s16) qm_mulu16(u16offset, (u16) (log_table[s16tableIndex + 1] - log_table[s16tableIndex])); With s16tableIndex + 1 we are trying an out-of-bounds access to the array. The log_table array provides log2 values in q.15 format and the above statement tries an error approximation with the next value. To fix this issue add the next value to the array and update the comment accordingly. Signed-off-by: Tobias Regnery <tobias.regnery@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Karthik D A authored
We will read fw_cap_info filled by firmware to check whether to skip ADHOC related commands or not. Also, IBSS_COALESCING_STATUS command has been moved from init path to adhoc network creation path. Signed-off-by: Karthik D A <karthida@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Wei Yongjun authored
Fixes the following sparse warning: drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c:1559:6: warning: symbol 'rtl8192eu_power_off' was not declared. Should it be static? Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Jes Sorensen authored
In order to obtain retry count for a given rate we need to pass the full struct ieee80211_tx_info to the function setting the rate in he TX descriptor. This uncovered a huge bug where the old code would use struct ieee80211_rate.flags to test for rate parameters, which is always zero, instead of the flags value from struct ieee80211_tx_rate. Time to find a brown paper bag :( Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Jes Sorensen authored
Use the mac80211 provided rate for RTS rather than the hard coded 24Mbps as suggested by the vendor drivers. Reported-by: Andrea Merello <andrea.merello@gmail.com> Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Jes Sorensen authored
The 8192eu suffered from two issues when reloading the driver. The same problems as with the 8723bu where REG_RX_WAIT_CCA bits 22 and 23 didn't get set in rtl8192e_enable_rf(). In addition it also seems prone to issues when setting REG_RF_CTRL to 0 intead of just disabling the RF_ENABLE bit. Similar to what was causing issues with the 8188eu. With this patch I can successfully reload the driver and reassociate to an APi with an 8192eu dongle. Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Jes Sorensen authored
The generic disable_rf() function clears bits 22 and 23 in REG_RX_WAIT_CCA, however we did not re-enable them again in rtl8723b_enable_rf() This resolves the problem for me with 8723bu devices not working again after reloading the driver. Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Jes Sorensen authored
The full RX descriptor is converted so converting tsfl again would return it to it's original endian value. Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Jes Sorensen authored
A device running without RX package aggregation could return more data in the USB packet than the actual network packet. In this case the could would clone the skb but then determine that that there was no packet to handle and exit without freeing the cloned skb first. This has so far only been observed with 8188eu devices, but could affect others. Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Brian Norris authored
We have a race where the wakeup IRQ might be in flight while we're calling mwifiex_disable_wake() from resume(). This can leave us disabling the IRQ twice. Let's disable the IRQ and enable it in case if we have double-disabled it. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Brian Norris authored
We don't want to leave the wake IRQ enabled. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Prameela Rani Garnepudi authored
Transmit power level in a channel is determined based on the dfs region. To support regulatory rules dfs region should be configured to device during set channel request. Also antenna gain values are taken from the mac80211 channel parameters instead of fixed values. Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Prameela Rani Garnepudi authored
RSI 9113 device supports single antenna for tx and rx. Support for using external is added. This can be configured from user space using iw. Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Prameela Rani Garnepudi authored
TX power can be configured from iwconfig, iw or from mac80211 when regulatory changes are done. Hence support for configuring tx power to device is added using the RADIO_PARAMS_UPDATE command frame. Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Prameela Rani Garnepudi authored
Filtering rx frames after connection in station mode avoids the overhead of processing un-necessary frames. Hence rx filter frame is added which can be configured to device at suitable times. Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
- 23 Nov, 2016 12 commits
-
-
Stanislaw Gruszka authored
Sending frames in CCK rates on HT can cause performance problems. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Stanislaw Gruszka authored
Use RTS/CTS protection for TXOP on all rates modes as default and disable CCK rates (this cause performance problems). Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Stanislaw Gruszka authored
Change default to RTS/CTS protection. This has a cost of transmitting one more control frame (RTS) however protect us from traffic from hidden node. On station mode will use CTS-to-self if AP will configure that for the network. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Stanislaw Gruszka authored
Those TX_SW_CFG1 values are used in vendor driver. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Stanislaw Gruszka authored
Initialize AUTO_RSP_CFG register to similar value as vendor driver does. Do not set BAC_ACK_POLICY based on short preamble setting, those are unrelated. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Stanislaw Gruszka authored
We already initlized WPDMA_GLO_CFG_WP_DMA_BURST_SIZE to 3 on rt2800_init_registers() for USB devices. For PCI devices we will use HW default setting, which is 2, so patch does not change behaviour on PCI devices. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Stanislaw Gruszka authored
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Stanislaw Gruszka authored
We should not reset USB_DMA_CFG on rt2800usb_init_registers() as this function is called indirectly from rt2800_enable_radio(). If we do so, we wipe out USB_DMA_CFG settings from rt2800usb_enable_radio(). Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Stanislaw Gruszka authored
We should only set IEEE80211_HT_MCS_TX_RX_DIF when TX and RX MCS sets are not equal, i.e. when number of tx streams is different than number of RX streams. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Wright Feng authored
Firmware doesn't update beacon/Probe Response vendor IEs correctly when bss is down, so we move brcmf_config_ap_mgmt_ie after BSS up. And host driver should clear IEs when AP stopped so that the IEs in host side will be synced with in firmware side. Signed-off-by: Wright Feng <wright.feng@cypress.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Vishal Thanki authored
In device removal routine, usage of "#ifdef CONFIG_RT2X00_LIB_USB" will not cover the case when it is configured as module. This will omit the entire if-block which does cleanup of URBs and cancellation of pending work. Changing the #ifdef to #if IS_ENABLED() to fix it. Signed-off-by: Vishal Thanki <vishalthanki@gmail.com> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo authored
ath.git patches for 4.10. Major changes: ath9k * add device tree bindings * switch to use mac80211 intermediate software queues to reduce latency and fix bufferbloat
-
- 19 Nov, 2016 9 commits
-
-
Brian Norris authored
It should never be NULL here, and to think otherwise makes things confusing. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Brian Norris authored
These are never NULL, so stop making people think they might be. I don't change this for SDIO because SDIO has a racy card-reset handler that reallocates this struct. I'd rather not touch that mess right now. Signed-off-by: Brian Norris <briannorris@chromium.org> Tested-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Brian Norris authored
sdio_func is retrieved via container_of() and should never be NULL. Checking for NULL just makes the logic more confusing than necessary. Stop doing that. Signed-off-by: Brian Norris <briannorris@chromium.org> Tested-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Brian Norris authored
SDIO and PCIe drivers handle this. Let's imitate it. Signed-off-by: Brian Norris <briannorris@chromium.org> Tested-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Xinming Hu authored
card->adapter gets initialized in mwifiex_register_dev(). As it's not cleared in mwifiex_unregister_dev(), we may end up accessing the memory which is already free in below scenario. Scenario: Driver initialization is failed due to incorrect firmware or some other reason. Meanwhile device reboot/unload occurs. This is safe, now that we've properly synchronized suspend() and remove() with the FW initialization thread; now that code can simply check for 'card->adapter == NULL' and exit safely. Signed-off-by: Xinming Hu <huxm@marvell.com> Tested-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Brian Norris authored
Signed-off-by: Brian Norris <briannorris@chromium.org> Tested-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Brian Norris authored
The device core will not allow suspend() to race with remove(). Signed-off-by: Brian Norris <briannorris@chromium.org> Tested-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Amitkumar Karwar authored
to_pci_dev() would just do struct offset arithmetic on struct device to get 'pdev' pointer. We never get NULL pdev pointer. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Tested-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Brian Norris authored
It's possible for the FW init sequence to fail, which will trigger a device cleanup sequence in mwifiex_fw_dpc(). This sequence can race with device suspend() or remove() (e.g., reboot or unbind), and can trigger use-after-free issues. Currently, this driver attempts (poorly) to synchronize remove() using a semaphore, but it doesn't protect some of the critical sections properly. Particularly, we grab a pointer to the adapter struct (card->adapter) without checking if it's being freed or not. We later do a NULL check on the adapter, but that doesn't work if the adapter was freed. Also note that the PCIe interface driver doesn't ever set card->adapter to NULL, so even if we get the synchronization right, we still might try to redo the cleanup in ->remove(), even if the FW init failure sequence already did it. This patch replaces the static semaphore with a per-device completion struct, and uses that completion to synchronize the remove() thread with the mwifiex_fw_dpc(). A future patch will utilize this completion to synchronize the suspend() thread as well. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-