- 20 Apr, 2017 30 commits
-
-
Yan-Hsuan Chuang authored
Use software dac swing and double check if it is sco_only to set the tdma for voice quality. Signed-off-by:
Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Cc: Pkshih <pkshih@realtek.com> Cc: Birming Chiu <birming@realtek.com> Cc: Shaofu <shaofu@realtek.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org>
-
Yan-Hsuan Chuang authored
1. Add more cases to adjust the wifi duration and add a case with the max interval of 3 for some future uses. 2. rename tdma_adj -> ps_tdma_du_adj to indicate that this member is for power saving tdma duration adjustment Signed-off-by:
-
Yan-Hsuan Chuang authored
The dac swing level should be an unsigned 32-bit value rather than boolean. Signed-off-by:
-
Yan-Hsuan Chuang authored
Depending on the state of wifi, we need to set different tdma and coex table parameters to make wfi and bt coexist smoothly. Otherwise the bt may have low sound quality or mouse lag, which mean bad user experience. The same problem may occur on wifi also, if could disconnect or lose some important packets. Signed-off-by:
-
Yan-Hsuan Chuang authored
If the wifi or bt has low rssi, they need extra parameter settings for the tdma. Signed-off-by:
-
Yan-Hsuan Chuang authored
Tune the wifi/bt slot time to get better performance. Signed-off-by:
-
Yan-Hsuan Chuang authored
Register 0xcb4 determines if the PTA circuit can control the swtich Signed-off-by:
-
Yan-Hsuan Chuang authored
Instead of just setting the coex table directly, we check if the wifi is under some important activity (scanning|roaming|linking) and mark the packets as high priority in that case. Signed-off-by:
-
Yan-Hsuan Chuang authored
When wifi is at 5G band, it does not intefere with 2.4G bt signal, hence we can just ignore it and transmit normally as nothing happened. Signed-off-by:
-
Yan-Hsuan Chuang authored
Monitor wifi status and check if it is changed. Signed-off-by:
-
Yan-Hsuan Chuang authored
Gather multiple coex table settings into a function coex_table_with_type() and control the coex table according the type value as put in switch-case expression. Signed-off-by:
-
Yan-Hsuan Chuang authored
Remove workaround for HT40 issues for RF low pass filter. Signed-off-by:
-
Yan-Hsuan Chuang authored
The power_save_state function checks the state of power saving. For tdma settings, the wifi sends nullfunc to pretend enter power saving and then bt can transmit. Hence the coex needs to check the power status before set the pstdma function. Signed-off-by:
-
Yan-Hsuan Chuang authored
Change h2c parameter to decrease tx penalty. Signed-off-by:
-
Yan-Hsuan Chuang authored
Gather variables to the 8821a2ant coex structure. Signed-off-by:
-
Yan-Hsuan Chuang authored
Originally we only increase/decrease bt power in a fixed power gap, this patch makes us be able to modify bt power for multiple power gaps and we can precisely adjust the bt power. Signed-off-by:
-
Yan-Hsuan Chuang authored
This function updates the information of bt profiling to help us decide the network status and dispatch the resource properly. Signed-off-by:
-
Yan-Hsuan Chuang authored
If there are a lot of low-rate packets, then the connection of wifi is unstable. If so, we should switch resource to bt to have a higher transmission quality, or wifi resource will be wasted Signed-off-by:
-
Yan-Hsuan Chuang authored
We monitor the packet counter to guess if the bt is slave or not, and when bt is slave, it may receive packet at any time, so we will have to take care about it Signed-off-by:
-
Yan-Hsuan Chuang authored
Larger packets have higher opportunity to be interrupt by bt signal. In order to shorten the transmission time, control the packet aggregation size. Signed-off-by:
-
Brian Norris authored
His email is bouncing, and he'd like to use this new one. Cc: Amitkumar Karwar <amitkarwar@gmail.com> Cc: Nishant Sarmukadam <nishants@marvell.com> Cc: Ganapathi Bhat <gbhat@marvell.com> Cc: Xinming Hu <huxm@marvell.com> Signed-off-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
-
Brian Norris authored
'chan_stats' is (re)allocated in _mwifiex_fw_dpc() -> mwifiex_init_channel_scan_gap(), which is called whenever the device is initialized -- at probe or at reset. But we only free it in we completely unregister the adapter, meaning we leak a copy of it during every reset. Let's free it in the shutdown / removal paths instead (and in the error-handling path), to avoid the leak. Ideally, we can eventually unify much of mwifiex_shutdown_sw() and mwifiex_remove_card() (way too much copy-and-paste) to reduce the burden on bugfixes like this. But that's work for tomorrow. Signed-off-by:
-
Brian Norris authored
When we shut down the device (i.e., during 'reset'), we cancel any outstanding work, but we don't clear any work-related flags. This can cause problems if, e.g., we begin to queue a new firmware dump or card reset while the other one is in progress. That might leave work_flags with a stale value, and we might begin one of these *after* we've completely reset the device. That doesn't make sense, because all firmware context will have been lost by then. This fixes some forms of cascading failures, where I: (a) force a firmware dump (cat /sys/kernel/debug/mwifiex/mlan0/device_dump) (b) run a Wifi scan in parallel (iw mlan0 scan) (c) the scan times out due to (a) hogging the interface (d) the command timeout triggers another firmware dump and a reset [*] (e) the 2nd firmware dump flag persists across the reset (f) as soon as the interface comes back up, we trigger the pending firmware dump (g) subsequent commands time out again, while we are processing the firmware dump; return to (d) [*] Note that automatic card_reset() support is not yet implemented for the mwifiex PCIe driver, so we won't hit *exactly* this behavior yet. But we can see similarly-confusing behaviors today. Signed-off-by: -
Brian Norris authored
If we reset because of a command timeout, we should reset this flag. Otherwise, we might erroneously think the next command after reset is timing out, and trigger another reset. The above behavior effectively neuters the automatic card_reset() behavior, as it means we will never recover from a command timeout properly (and in fact, we might enter an infinite loop: timeout -> reset -> (fake) timeout -> reset -> ... This fixes a bug introduced with introduction of PCIe function level reset support, but it was carried into the SDIO driver when it was converted to use the same codepaths. And this is currently mostly a problem only in the SDIO driver, because it's the only one with automatic card_reset() support (e.g., on command timeout). But it will be a problem for PCIe too, as I'm working on supporting automatic card_reset() for PCIe. Fixes: c742e623 ("mwifiex: sdio card reset enhancement") Fixes: 4c5dae59 ("mwifiex: add PCIe function level reset support") Signed-off-by:
-
Brian Norris authored
Command buffers (skb's) are allocated by the main driver, and freed upon the last use. That last use is often in mwifiex_free_cmd_buffer(). In the meantime, if the command buffer gets used by the PCI driver, we map it as DMA-able, and store the mapping information in the 'cb' memory. However, if a command was in-flight when resetting the device (and therefore was still mapped), we don't get a chance to unmap this memory until after the core has cleaned up its command handling. Let's keep a refcount within the PCI driver, so we ensure the memory only gets freed after we've finished unmapping it. Noticed by KASAN when forcing a reset via: echo 1 > /sys/bus/pci/.../reset The same code path can presumably be exercised in remove() and shutdown(). [ 205.390377] mwifiex_pcie 0000:01:00.0: info: shutdown mwifiex... [ 205.400393] ================================================================== [ 205.407719] BUG: KASAN: use-after-free in mwifiex_unmap_pci_memory.isra.14+0x4c/0x100 [mwifiex_pcie] at addr ffffffc0ad471b28 [ 205.419040] Read of size 16 by task bash/1913 [ 205.423421] ============================================================================= [ 205.431625] BUG skbuff_head_cache (Tainted: G B ): kasan: bad access detected [ 205.439815] ----------------------------------------------------------------------------- [ 205.439815] [ 205.449534] INFO: Allocated in __build_skb+0x48/0x114 age=1311 cpu=4 pid=1913 [ 205.456709] alloc_debug_processing+0x124/0x178 [ 205.461282] ___slab_alloc.constprop.58+0x528/0x608 [ 205.466196] __slab_alloc.isra.54.constprop.57+0x44/0x54 [ 205.471542] kmem_cache_alloc+0xcc/0x278 [ 205.475497] __build_skb+0x48/0x114 [ 205.479019] __netdev_alloc_skb+0xe0/0x170 [ 205.483244] mwifiex_alloc_cmd_buffer+0x68/0xdc [mwifiex] [ 205.488759] mwifiex_init_fw+0x40/0x6cc [mwifiex] [ 205.493584] _mwifiex_fw_dpc+0x158/0x520 [mwifiex] [ 205.498491] mwifiex_reinit_sw+0x2c4/0x398 [mwifiex] [ 205.503510] mwifiex_pcie_reset_notify+0x114/0x15c [mwifiex_pcie] [ 205.509643] pci_reset_notify+0x5c/0x6c [ 205.513519] pci_reset_function+0x6c/0x7c [ 205.517567] reset_store+0x68/0x98 [ 205.521003] dev_attr_store+0x54/0x60 [ 205.524705] sysfs_kf_write+0x9c/0xb0 [ 205.528413] INFO: Freed in __kfree_skb+0xb0/0xbc age=131 cpu=4 pid=1913 [ 205.535064] free_debug_processing+0x264/0x370 [ 205.539550] __slab_free+0x84/0x40c [ 205.543075] kmem_cache_free+0x1c8/0x2a0 [ 205.547030] __kfree_skb+0xb0/0xbc [ 205.550465] consume_skb+0x164/0x178 [ 205.554079] __dev_kfree_skb_any+0x58/0x64 [ 205.558304] mwifiex_free_cmd_buffer+0xa0/0x158 [mwifiex] [ 205.563817] mwifiex_shutdown_drv+0x578/0x5c4 [mwifiex] [ 205.569164] mwifiex_shutdown_sw+0x178/0x310 [mwifiex] [ 205.574353] mwifiex_pcie_reset_notify+0xd4/0x15c [mwifiex_pcie] [ 205.580398] pci_reset_notify+0x5c/0x6c [ 205.584274] pci_dev_save_and_disable+0x24/0x6c [ 205.588837] pci_reset_function+0x30/0x7c [ 205.592885] reset_store+0x68/0x98 [ 205.596324] dev_attr_store+0x54/0x60 [ 205.600017] sysfs_kf_write+0x9c/0xb0 ... [ 205.800488] Call trace: [ 205.802980] [<ffffffc00020a69c>] dump_backtrace+0x0/0x190 [ 205.808415] [<ffffffc00020a96c>] show_stack+0x20/0x28 [ 205.813506] [<ffffffc0005d020c>] dump_stack+0xa4/0xcc [ 205.818598] [<ffffffc0003be44c>] print_trailer+0x158/0x168 [ 205.824120] [<ffffffc0003be5f0>] object_err+0x4c/0x5c [ 205.829210] [<ffffffc0003c45bc>] kasan_report+0x334/0x500 [ 205.834641] [<ffffffc0003c3994>] check_memory_region+0x20/0x14c [ 205.840593] [<ffffffc0003c3b14>] __asan_loadN+0x14/0x1c [ 205.845879] [<ffffffbffc46171c>] mwifiex_unmap_pci_memory.isra.14+0x4c/0x100 [mwifiex_pcie] [ 205.854282] [<ffffffbffc461864>] mwifiex_pcie_delete_cmdrsp_buf+0x94/0xa8 [mwifiex_pcie] [ 205.862421] [<ffffffbffc462028>] mwifiex_pcie_free_buffers+0x11c/0x158 [mwifiex_pcie] [ 205.870302] [<ffffffbffc4620d4>] mwifiex_pcie_down_dev+0x70/0x80 [mwifiex_pcie] [ 205.877736] [<ffffffbffc1397a8>] mwifiex_shutdown_sw+0x190/0x310 [mwifiex] [ 205.884658] [<ffffffbffc4606b4>] mwifiex_pcie_reset_notify+0xd4/0x15c [mwifiex_pcie] [ 205.892446] [<ffffffc000635f54>] pci_reset_notify+0x5c/0x6c [ 205.898048] [<ffffffc00063a044>] pci_dev_save_and_disable+0x24/0x6c [ 205.904350] [<ffffffc00063cf0c>] pci_reset_function+0x30/0x7c [ 205.910134] [<ffffffc000641118>] reset_store+0x68/0x98 [ 205.915312] [<ffffffc000771588>] dev_attr_store+0x54/0x60 [ 205.920750] [<ffffffc00046f53c>] sysfs_kf_write+0x9c/0xb0 [ 205.926182] [<ffffffc00046dfb0>] kernfs_fop_write+0x184/0x1f8 [ 205.931963] [<ffffffc0003d64f4>] __vfs_write+0x6c/0x17c [ 205.937221] [<ffffffc0003d7164>] vfs_write+0xf0/0x1c4 [ 205.942310] [<ffffffc0003d7da0>] SyS_write+0x78/0xd8 [ 205.947312] [<ffffffc000204634>] el0_svc_naked+0x24/0x28 ... [ 205.998268] ================================================================== This bug has been around in different forms for a while. It was sort of noticed in commit 955ab095 ("mwifiex: Do not kfree cmd buf while unregistering PCIe"), but it just fixed the double-free, without acknowledging the potential for use-after-free. Fixes: fc331460 ("mwifiex: use pci_alloc/free_consistent APIs for PCIe") Cc: <stable@vger.kernel.org> Signed-off-by:
-
Xinming Hu authored
A separate wifi-only firmware was download during pcie function level reset. It is in fact the tail part of wifi/bt combo firmware. Per Brian's and Dmitry's suggestion, this patch extract the wifi part from combo firmware. After that, the mrvl/pcie8997_wlan_v4.bin image in linux-firmware repo is redundant (though I guess we keep it around to support older kernels). Signed-off-by:
Xinming Hu <huxm@marvell.com> Signed-off-by:
Ganapathi Bhat <gbhat@marvell.com> Signed-off-by:
Cathy Luo <cluo@marvell.com> Signed-off-by:
-
Xinming Hu authored
This patch correct pcie scratch register name, to keep the same with chipset side definition. Signed-off-by:
-
Xinming Hu authored
mwifiex_dbg will do nothing before adapter->dev get assigned. several logs lost in this case. it can be avoided by fall back to pr_info. Signed-off-by:
Dmitry Torokhov <dtor@chromium.org> Signed-off-by:
-
Xinming Hu authored
If wakeup interrupt handler is called, we know that the wakeup interrupt number is valid, there is no need to check it. Signed-off-by:
-
Brian Norris authored
nl80211 provides the NL80211_SCAN_FLAG_RANDOM_ADDR for every scan request that should be randomized; the absence of such a flag means we should not randomize. However, mwifiex was stashing the latest randomization request and *always* using it for future scans, even those that didn't set the flag. Let's zero out the randomization info whenever we get a scan request without NL80211_SCAN_FLAG_RANDOM_ADDR. I'd prefer to remove priv->random_mac entirely (and plumb the randomization MAC properly through the call sequence), but the spaghetti is a little difficult to unravel here for me. Fixes: c2a8f0ff ("mwifiex: support random MAC address for scanning") Cc: <stable@vger.kernel.org> # 4.9+ Signed-off-by:
-
- 19 Apr, 2017 1 commit
-
-
Arend Van Spriel authored
The fwsignal module is only referenced by the bcdc module and part of the bcdc protocol. So only build it when CONFIG_BRCMFMAC_PROTO_BCDC is selected. Fixes: acf8ac41 ("brcmfmac: remove reference to fwsignal data from struct brcmf_pub") Signed-off-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by:
-
- 18 Apr, 2017 1 commit
-
-
Kalle Valo authored
Merge tag 'iwlwifi-next-for-kalle-2017-04-13' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next Patches intended for v4.12: * Some small fixes here and there; * The usual cleanups and small improvements; * Work to support A000 devices continues; * New FW API version; * Some debugging improvements;
-
- 13 Apr, 2017 8 commits
-
-
Daniel Golle authored
Consequently refer to external PA instead of inverting the logic and use an internal PA capability flag which is a bit confusing. Currently this is used for Rt3352 only, but MT7620A also allows for an external PA which will be supported by a follow up patch. Signed-off-by:
Daniel Golle <daniel@makrotopia.org> Acked-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
Yan-Hsuan Chuang authored
When driver is going to sleep, it does not leave LPS/IPS, thus the BTCoex may have mismatch when driver wakes up. To avoid that, BTCoex needs to clear the IPS/LPS state when it receives a pnp notify, then it can properly set up the hw when driver wakes up. Signed-off-by:
-
Yan-Hsuan Chuang authored
When wifi is on a 5G channel, the 5G signal will not interfere bt 2.4G signal, and they can transmit simultaneously, hence there is no need to switch antenna between wifi and bt. Signed-off-by:
-
Yan-Hsuan Chuang authored
When wifi is scanning and not connected, set the tdma and coex table properly to control the priority of the packets to make the wifi bt coexistence operate smoothly Signed-off-by:
-
Yan-Hsuan Chuang authored
With bt inquiry, the wifi may start as a softap or the wifi and bt are busy, we take these scenarios into consider to avoid bt inquiry to degrade the performance of the network Signed-off-by:
-
Yan-Hsuan Chuang authored
Move the bt disable flag to a global structure to indicate that bt is turned off. Signed-off-by:
-
Yan-Hsuan Chuang authored
If the device has wifi mode only, there is no need to initiate the hardware for wifi and bt coexistence, so just return to avoid it. Signed-off-by:
-
Yan-Hsuan Chuang authored
When wifi is associating or authenticating, set the coex table for wifi to establish link. These packets should have higher priority. Signed-off-by:
-
