aboutsummaryrefslogtreecommitdiff
path: root/drivers/net/wireless/mwifiex
AgeCommit message (Collapse)Author
2013-09-14mwifiex: do not create AP and P2P interfaces upon driver loadingBing Zhao
commit 1211c961170cedb21c30d5bb7e2033c8720b38db upstream. Bug 60747 - 1286:2044 [Microsoft Surface Pro] Marvell 88W8797 wifi show 3 interface under network https://bugzilla.kernel.org/show_bug.cgi?id=60747 This issue was also reported previously by OLPC and some folks from the community. There are 3 network interfaces with different types being created when mwifiex driver is loaded: 1. mlan0 (infra. STA) 2. uap0 (AP) 3. p2p0 (P2P_CLIENT) The Network Manager attempts to use all 3 interfaces above without filtering the managed interface type. As the result, 3 identical interfaces are displayed under network manager. If user happens to click on an entry under which its interface is uap0 or p2p0, the association will fail. Work around it by removing the creation of AP and P2P interfaces at driver loading time. These interfaces can be added with 'iw' or other applications manually when they are needed. Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11mwifiex: fix wrong data rates in P2P clientAvinash Patil
commit 237b2ac8ac89a6b0120decdd05c7bf4637deb98a upstream. This patch fixes an issue wherein adhoc rates were being copied into association request from P2P client. Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Stone Piao <piaoyun@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11mwifiex: check for bss_role instead of bss_mode for STA operationsAvinash Patil
commit 953b3539ef9301b8ef73f4b6e2fd824b86aae65a upstream. This patch fixes an issue wherein association would fail on P2P interfaces. This happened because we are checking priv->mode against NL80211_IFTYPE_STATION. While this check is correct for infrastructure stations, it would fail P2P clients for which mode is NL80211_IFTYPE_P2P_CLIENT. Better check would be bss_role which has only 2 values: STA/AP. Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Stone Piao <piaoyun@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11mwifiex: Add missing endian conversion.Tomasz Moń
commit 83e612f632c3897be29ef02e0472f6d63e258378 upstream. Both type and pkt_len variables are in host endian and these should be in Little Endian in the payload. Signed-off-by: Tomasz Moń <desowin@gmail.com> Acked-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-12mwifiex: debugfs: Fix out of bounds array accessMark A. Greer
When reading the contents of '/sys/kernel/debug/mwifiex/p2p0/info', the following panic occurs: $ cat /sys/kernel/debug/mwifiex/p2p0/info Unable to handle kernel paging request at virtual address 74706164 pgd = de530000 [74706164] *pgd=00000000 Internal error: Oops: 5 [#1] SMP ARM Modules linked in: phy_twl4030_usb omap2430 musb_hdrc mwifiex_sdio mwifiex CPU: 0 PID: 1635 Comm: cat Not tainted 3.10.0-rc1-00010-g1268390 #1 task: de16b6c0 ti: de048000 task.ti: de048000 PC is at strnlen+0xc/0x4c LR is at string+0x3c/0xf8 pc : [<c02c123c>] lr : [<c02c2d1c>] psr: a0000013 sp : de049e10 ip : c06efba0 fp : de6d2092 r10: bf01a260 r9 : ffffffff r8 : 74706164 r7 : 0000ffff r6 : ffffffff r5 : de6d209c r4 : 00000000 r3 : ff0a0004 r2 : 74706164 r1 : ffffffff r0 : 74706164 Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 9e530019 DAC: 00000015 Process cat (pid: 1635, stack limit = 0xde048240) Stack: (0xde049e10 to 0xde04a000) 9e00: de6d2092 00000002 bf01a25e de6d209c 9e20: de049e80 c02c438c 0000000a ff0a0004 ffffffff 00000000 00000000 de049e48 9e40: 00000000 2192df6d ff0a0004 ffffffff 00000000 de6d2092 de049ef8 bef3cc00 9e60: de6b0000 dc358000 de6d2000 00000000 00000003 c02c45a4 bf01790c bf01a254 9e80: 74706164 bf018698 00000000 de59c3c0 de048000 de049f80 00001000 bef3cc00 9ea0: 00000008 00000000 00000000 00000000 00000000 00000000 00000000 00000000 9ec0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 9ee0: 00000000 00000000 00000000 00000001 00000000 00000000 6669776d 20786569 9f00: 20302e31 2e343128 392e3636 3231702e 00202933 00000000 00000003 c0294898 9f20: 00000000 00000000 00000000 00000000 de59c3c0 c0107c04 de554000 de59c3c0 9f40: 00001000 bef3cc00 de049f80 bef3cc00 de049f80 00000000 00000003 c0108a00 9f60: de048000 de59c3c0 00000000 00000000 de59c3c0 00001000 bef3cc00 c0108b60 9f80: 00000000 00000000 00001000 bef3cc00 00000003 00000003 c0014128 de048000 9fa0: 00000000 c0013f80 00001000 bef3cc00 00000003 bef3cc00 00001000 00000000 9fc0: 00001000 bef3cc00 00000003 00000003 00000001 00000001 00000001 00000003 9fe0: 00000000 bef3cbdc 00011984 b6f1127c 60000010 00000003 18dbdd2c 7f7bfffd [<c02c123c>] (strnlen+0xc/0x4c) from [<c02c2d1c>] (string+0x3c/0xf8) [<c02c2d1c>] (string+0x3c/0xf8) from [<c02c438c>] (vsnprintf+0x1e8/0x3e8) [<c02c438c>] (vsnprintf+0x1e8/0x3e8) from [<c02c45a4>] (sprintf+0x18/0x24) [<c02c45a4>] (sprintf+0x18/0x24) from [<bf01790c>] (mwifiex_info_read+0xfc/0x3e8 [mwifiex]) [<bf01790c>] (mwifiex_info_read+0xfc/0x3e8 [mwifiex]) from [<c0108a00>] (vfs_read+0xb0/0x144) [<c0108a00>] (vfs_read+0xb0/0x144) from [<c0108b60>] (SyS_read+0x44/0x70) [<c0108b60>] (SyS_read+0x44/0x70) from [<c0013f80>] (ret_fast_syscall+0x0/0x30) Code: e12fff1e e3510000 e1a02000 0a00000d (e5d03000) ---[ end trace ca98273dc605a04f ]--- The panic is caused by the mwifiex_info_read() routine assuming that there can only be four modes (0-3) which is an invalid assumption. For example, when testing P2P, the mode is '8' (P2P_CLIENT) so the code accesses data beyond the bounds of the bss_modes[] array which causes the panic. Fix this by updating bss_modes[] to support the current list of modes and adding a check to prevent the out-of-bounds access from occuring in the future when more modes are added. Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Acked-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-05-10Merge branch 'master' of ↵John W. Linville
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
2013-05-08mwifiex: fix setting of multicast filterDaniel Drake
A small bug in this code was causing the ALLMULTI filter to be set when in fact we were just wanting to program a selective multicast list to the hardware. Fix that bug and remove a redundant if condition in the code that follows. This fixes wakeup behaviour when multicast WOL is enabled. Previously, all multicast packets would wake up the system. Now, only those that the host intended to receive trigger wakeups. Signed-off-by: Daniel Drake <dsd@laptop.org> Cc: <stable@vger.kernel.org> Acked-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-05-08mwifiex: fix memory leak issue when driver unloadAmitkumar Karwar
After unregister_netdevice() call the request is queued and reg_state is changed to NETREG_UNREGISTERING. As we check for NETREG_UNREGISTERED state, free_netdev() never gets executed causing memory leak. Initialize "dev->destructor" to free_netdev() to free device data after unregistration. Cc: <stable@vger.kernel.org> Reported-by: Daniel Drake <dsd@laptop.org> Tested-by: Daniel Drake <dsd@laptop.org> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-05-08mwifiex: clear is_suspended flag when interrupt is received earlyBing Zhao
When the XO-4 with 8787 wireless is woken up due to wake-on-WLAN mwifiex is often flooded with "not allowed while suspended" messages and the interface is unusable. [ 202.171609] int: sdio_ireg = 0x1 [ 202.180700] info: mwifiex_process_hs_config: auto cancelling host sleep since there is interrupt from the firmware [ 202.201880] event: wakeup device... [ 202.211452] event: hs_deactivated [ 202.514638] info: --- Rx: Data packet --- [ 202.514753] data: 4294957544 BSS(0-0): Data <= kernel [ 202.514825] PREP_CMD: device in suspended state [ 202.514839] data: dequeuing the packet ec7248c0 ec4869c0 [ 202.514886] mwifiex_write_data_sync: not allowed while suspended [ 202.514886] host_to_card, write iomem (1) failed: -1 [ 202.514917] mwifiex_write_data_sync: not allowed while suspended [ 202.514936] host_to_card, write iomem (2) failed: -1 [ 202.514949] mwifiex_write_data_sync: not allowed while suspended [ 202.514965] host_to_card, write iomem (3) failed: -1 [ 202.514976] mwifiex_write_data_async failed: 0xFFFFFFFF This can be readily reproduced when putting the XO-4 in a loop where it goes to sleep due to inactivity, but then wakes up due to an incoming ping. The error is hit within an hour or two. This issue happens when an interrupt comes in early while host sleep is still activated. Driver handles this case by auto cancelling host sleep. However is_suspended flag is still set which prevents any cmd or data from being sent to firmware. Fix it by clearing is_suspended flag in this path. Cc: <stable@vger.kernel.org> Reported-by: Daniel Drake <dsd@laptop.org> Tested-by: Daniel Drake <dsd@laptop.org> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-05-07drivers/net: rename random32() to prandom_u32()Akinobu Mita
Use preferable function name which implies using a pseudo-random number generator. [akpm@linux-foundation.org: convert team_mode_random.c] Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Acked-by: Thomas Sailer <t.sailer@alumni.ethz.ch> Acked-by: Bing Zhao <bzhao@marvell.com> [mwifiex] Cc: "David S. Miller" <davem@davemloft.net> Cc: Michael Chan <mchan@broadcom.com> Cc: Thomas Sailer <t.sailer@alumni.ethz.ch> Cc: Jean-Paul Roubelat <jpr@f6fbb.org> Cc: Bing Zhao <bzhao@marvell.com> Cc: Brett Rudley <brudley@broadcom.com> Cc: Arend van Spriel <arend@broadcom.com> Cc: "Franky (Zhenhui) Lin" <frankyl@broadcom.com> Cc: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-26mwifiex: Correct pci_unmap_single's sizeYogesh Ashok Powar
There exist mismatch between the size used for pci_map and pci_unmap on command skb. Correcting it. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-04-26mwifiex: Do not kfree cmd buf while unregistering PCIeYogesh Ashok Powar
All the command buffers are freed in mwifiex_free_cmd_buffer() and hence there is no need to kfree the current command buffer again. This might ends up freeing memory allocated by some other kernel code. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-04-26mwifiex: Call pci_release_region after calling pci_disable_deviceYogesh Ashok Powar
"drivers should call pci_release_region() AFTER calling pci_disable_device()" Please refer section 3.2 Request MMIO/IOP resources in Documentation/PCI/pci.txt Cc: <stable@vger.kernel.org> # 3.2+ Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-04-26mwifiex: Use pci_release_region() instead of a pci_release_regions()Yogesh Ashok Powar
PCI regions are associated with the device using pci_request_region() call. Hence use pci_release_region() instead of pci_release_regions(). Cc: <stable@vger.kernel.org> # 3.2+ Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-04-23mwifiex: rework round robin scheduling of bss nodes.Andreas Fenkart
Rotate bss prio list, so the bss next to the one served, will come first in the list of bss' with equal priority. This way we pick bss nodes in a round robin fashion. Using list rotation instead of a cur ptr simplifies iteration to calling list_for_each_entry. List rotation is done via list_move, where the head itself is temporarily removed and then re-inserted after the bss just served. Signed-off-by: Andreas Fenkart <andreas.fenkart@streamunlimited.com> Acked-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-04-23mwifiex: replace ra_list_curr by list rotation.Andreas Fenkart
After a packet is successfully transmitted, ra list is rotated, so the ra next to the one transmitted, will be the first in the list. This way we pick the ra' in a round robin fashion. This significantly simplifies iteration in mwifiex_wmm_get_highest_priolist_ptr to a call to list_for_each_entry. List rotation is done via list_move, where the head itself is temporarily removed and then re-inserted after the item just transferred. Signed-off-by: Andreas Fenkart <andreas.fenkart@streamunlimited.com> Acked-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-04-22mwifiex: remove redundant initialization for bss_descriptorBing Zhao
Initialization of bss_descriptor is unnecessary as the entire structure will be overwritten by a memcpy followed by. Initialize disable_11ac flag properly by setting it to true in mwifiex_fill_new_bss_desc(). Reported-by: Doug Anderson <dianders@chromium.org> Reviewed-by: Doug Anderson <dianders@chromium.org> Reviewed-by: Paul Stewart <pstew@chromium.org> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-04-22mwifiex: fix use-after-free in beacon_ie processingBing Zhao
beacon_ie buffer is allocated in mwifiex_fill_new_bss_desc() and the buffer pointer is saved in bss_desc->beacon_buf. beacon_ie is freed before the function returns. However, bss_desc->beacon_buf is still being accessed afterwards. Fix it by freeing beacon_ie (bss_desc->beacon_buf) in caller's scope. Reviewed-by: Doug Anderson <dianders@chromium.org> Reviewed-by: Paul Stewart <pstew@chromium.org> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-04-22mwifiex: don't try to associate when bss_mode is not STABing Zhao
We have blocked association attempts on interfaces configured in AP and AD-HOC modes. P2P mode should be blocked too. Furthermore, an error code must be returned if we are unable to associate. Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-04-22mwifiex: make use of msecs_to_jiffies()Bing Zhao
Use msecs_to_jiffies() wherever possible. Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-04-22mwifiex: correct bss_mode check while appending vht operation IEBing Zhao
priv->bss_mode uses NL80211_IFTYPE_* definitions. HostCmd_BSS_MODE_IBSS is used in ad-hoc start/join command between driver and firmware. Coincidentally both HostCmd_BSS_MODE_IBSS and NL80211_IFTYPE_STATION are defined as 2. That explains why nobody complained. Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-04-22mwifiex: use PCI_DMA_FROMDEVICE for RX queue de-initAvinash Patil
There is a typo in mwifiex_cleanup_rxq_ring() which uses PCI_DMA_TODEVICE while unmapping PCI memory. We should actually use PCI_DMA_FROMDEVICE. Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-04-22mwifiex: configure p2p interface during initializationBing Zhao
Send P2P_MODE_CFG cmd to firmware when p2p interface is created. Without proper p2p configuration firmware may behave incorrectly while handling commands sent through this interface. Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Stone Piao <piaoyun@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-04-22mwifiex: Start P2P devices in P2P modePaul Stewart
p2p devices should identify themselves as such to userspace at startup, so the connection manager can decide which interface to start wpa_supplicant instances on. Signed-off-by: Paul Stewart <pstew@chromium.org> Reviewed-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-04-10Merge branch 'master' of ↵John W. Linville
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless Conflicts: drivers/net/wireless/rt2x00/rt2x00pci.c
2013-04-08mwifiex: hold proper locks when accessing ra_list / bss_prio listsAndreas Fenkart
Not locking ra_list when dequeuing packets creates race conditions. When adding a packet 'tx_pkts_queued' is modified before setting highest_priority_queue. If in-between the main loop starts, it will see a packet queued (tx_pkts_queued > 0) but will not find it, since max prio is not set yet. Depending on the scheduling, the thread trying to add the packet could complete and restore the situation. But this is not something to rely on. Another race condition exists, if a new packet, exceeding current max prio is added. If concurrently a packet is dequeued, the newly set max prio will be overwritten with the value of the dequeued packet. This can occur, because selecting a packet and modifying the max prio is not atomic. The result in an infinite loop unless, a new packet is added that has at least the priority of the hidden packet. Same applies to bss_prio_tbl. Forward iteration is no proper lock-free technique and provides no protection from calls to list_del. Although BSS are currently not added/removed dynamically, this must not be the case in the future. Hence always hold proper locks when accessing those lists. Signed-off-by: Andreas Fenkart <andreas.fenkart@streamunlimited.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-04-08mwifiex: fix infinite loop by removing NO_PKT_PRIO_TIDAndreas Fenkart
Using NO_PKT_PRIO_TID and tx_pkts_queued to check for an empty state, can lead to a contradictory state, resulting in an infinite loop. Currently queueing and dequeuing of packets is not synchronized, and can happen concurrently. While tx_pkts_queued is incremented when adding a packet, max prio is set to NO_PKT when the WMM list is empty. If a packet is added right after the check for empty, but before setting max prio to NO_PKT, that packet is trapped and creates an infinite loop. Because of the new packet, tx_pkts_queued is at least 1, indicating wmm lists are not empty. Opposing that max prio is NO_PKT, which means "skip this wmm queue, it has no packets". The infinite loop results, because the main loop checks the wmm lists for not empty via tx_pkts_queued, but for dequeing it uses max_prio to see if it can skip current list. This will never end, unless a new packet is added which will restore max prio to the level of the trapped packet. The solution here is to rely on tx_pkts_queued solely for checking wmm queue to be empty, and drop the NO_PKT define. It does not address the locking issue. Signed-off-by: Andreas Fenkart <andreas.fenkart@streamunlimited.com> Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-04-08mwifiex: remove unused tid_tbl_lock from mwifiex_tid_tblAndreas Fenkart
ra_list_spinlock is used to protect struct mwifiex_wmm_desc and embedded structures such as ra_list. tid_tbl_lock while more fine grained, is not used but in one function. That function is not called reentrantly. To protect ra_list from concurrent modification ra_list_spinlock must be held. Signed-off-by: Andreas Fenkart <andreas.fenkart@streamunlimited.com> Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-04-08mwifiex: correct wrong list in list_empty checkAndreas Fenkart
adapter->bss_prio_tbl list has already been checked in outer loop. The inner loop works with priv_tmp->wmm.tid_tbl_ptr list. Also the lock taken, gives hint that this is likely a copy-paste error. Signed-off-by: Andreas Fenkart <andreas.fenkart@streamunlimited.com> Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-04-08mwifiex: fix negative cmd_pending countBing Zhao
cmd_pending is increased in mwifiex_wait_queue_complete() and decreased in mwifiex_complete_cmd() currently. If there are two or more commands in the cmd_pending_q the main worker thread will pick up next command from cmd_pending_q automatically after finishing current command. As a result mwifiex_wait_queue_complete() will not be called because the command is alreay completed. This leads to a negative number in cmd_pending count. Fix it by increasing cmd_pending when a cmd is queued into cmd_pending_q and decreasing when that cmd is recycled. For scan commands we don't perform inc/dec operations until it's moved from scan_pending_q to cmd_pending_q. This covers both synchronous and asynchronous commands. Reported-by: Daniel Drake <dsd@laptop.org> Tested-by: Daniel Drake <dsd@laptop.org> Tested-by: Marco Cesarano <marco@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-04-03mwifiex: complete last internal scanBing Zhao
We are waiting on first scan command of internal scan request before association, so we should complete on last internal scan command response. Cc: <stable@vger.kernel.org> # 3.8 Tested-by: Daniel Drake <dsd@laptop.org> Tested-by: Marco Cesarano <marco@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-04-01mwifiex: use separate AMPDU tx/rx window sizes in 11ac networksAvinash Patil
Newer 11ac enabled chipsets have more TX and RX buffers in FW and hardware; so they may support larger TX and RX window sizes for BA. Reset BA settings during association, adhoc join/start or start_ap() if we are joining/creating 11ac network. Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Sagar Bijwe <bsagar@marvell.com> Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-04-01mwifiex: change default tx/rx win_size for BA setupAvinash Patil
This patch fixes an issue where RX throughput values observed were substantially lower than TX counterparts for PCIe8897 STA. PCIe8897 supports larger rx_win_size. After changing these values we see big improvement for TX and RX throughput values. Different tx_win_size and rx_win_size are used for AP mode. All BA setup related initialization has been moved to separate function. Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Sagar Bijwe <bsagar@marvell.com> Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-04-01mwifiex: limit channel number not to overflow memoryStone Piao
Limit the channel number in scan request, or the driver scan config structure memory will be overflowed. Cc: <stable@vger.kernel.org> # 3.5+ Signed-off-by: Stone Piao <piaoyun@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-03-29Merge branch 'master' of ↵John W. Linville
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless Conflicts: net/mac80211/sta_info.c net/wireless/core.h
2013-03-27mwifiex: use fw_status register to wake up PCIe cardAvinash Patil
FW can be woken up even by accessing device registers; we need not explicitily enable interrupts for doing this. Future PCIe devices will not be woken up by writing to host registers. This patch enables driver to wake up device by reading FW status register. Also devices with sleep cookie enabled need some more time before proceeding with processing. Handle this by adding a delay loop. Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-03-27mwifiex: avoid waking up device in awake stateAvinash Patil
We have received interrupt from device means FW is not sleeping. In this case make sure wakeup handler for PCIe is not invoked by setting adapter->pm_wakeup_fw_try to false. Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-03-27mwifiex: do not enable PCIe interrupt in Power Save sleep stateAvinash Patil
Enabling PCIe host interrupt may accidently wake up the card when it's in sleep. Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-03-25mwifiex: add support to configure VHT for AP modeYogesh Ashok Powar
Currently, default VHT configuration from the firmware is used for the VHT operations. Adding vhtcfg command to configure the firmware based on input received from cfg. Enable VHT for AP mode only when cfg80211_ap_settings has a VHT IE i.e., when ieee80211ac is set to 1 in the hostapd.conf. Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-03-25mwifiex: reset skb->data after processing PCIe sleep confirm cmd resposeAvinash Patil
This patch is a bug fix for an issue wherein power save was not working for PCIe. This happens because for processing power save sleep confirm command we pull skb so that skb->data points ahead of interface header. We use same skb to get other cmda responses as well. So if we don't push skb after processing cmd response, it results into reduction in skb->len and finally skb->len reaches zero. This causes failure in processing sleep command response. Fix this by pushing skb by INTF_HEADER_LEN at the end of command response processing. Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-03-18mwifiex: cleanup VHT capYogesh Ashok Powar
Firmware returned VHT cap has the same format that cfg80211 expects. There is no need to parse the vht cap from the firmware and then set it to ieee80211_sta_vht_cap. Just copying is sufficient. Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-03-18mwifiex: cancel cmd timer and free curr_cmd in shutdown processBing Zhao
curr_cmd points to the command that is in processing or waiting for its command response from firmware. If the function shutdown happens to occur at this time we should cancel the cmd timer and put the command back to free queue. Cc: <stable@vger.kernel.org> # 3.8 Tested-by: Marco Cesarano <marco@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-03-18mwifiex: skip pending commands after function shutdownBing Zhao
During rmmod mwifiex_sdio processing FUNC_SHUTDOWN command is sent to firmware. Firmware expcets only FUNC_INIT once WLAN function is shut down. Any command pending in the command queue should be ignored and freed. Cc: <stable@vger.kernel.org> # 3.8 Tested-by: Daniel Drake <dsd@laptop.org> Tested-by: Marco Cesarano <marco@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-03-18mwifiex: fix race when queuing commandsAmitkumar Karwar
Running the following script repeatedly on XO-4 with SD8787 produces command timeout and system lockup. insmod mwifiex_sdio.ko sleep 1 ifconfig eth0 up iwlist eth0 scan & sleep 0.5 rmmod mwifiex_sdio mwifiex_send_cmd_async() is called for sync as well as async commands. (mwifiex_send_cmd_sync() internally calls it for sync command.) "adapter->cmd_queued" gets filled inside mwifiex_send_cmd_async() routine for both types of commands. But it is used only for sync commands in mwifiex_wait_queue_complete(). This could lead to a race when two threads try to queue a sync command with another sync/async command simultaneously. Get rid of global variable and pass command node as a parameter to mwifiex_wait_queue_complete() to fix the problem. Cc: <stable@vger.kernel.org> # 3.8 Reported-by: Daniel Drake <dsd@laptop.org> Tested-by: Daniel Drake <dsd@laptop.org> Tested-by: Marco Cesarano <marco@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-03-18Merge branch 'master' of ↵John W. Linville
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless Conflicts: net/nfc/llcp/llcp.c
2013-03-08mwifiex: fix potential null dereference 'mef_entry'Bing Zhao
drivers/net/wireless/mwifiex/cfg80211.c:2357 mwifiex_cfg80211_suspend() error: potential null dereference 'mef_entry' (kzalloc returns null) Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-03-08mwifiex: Trigger a card reset on reaching tx_timeout thresholdAshok Nagarajan
tx_timeout doesn't always lead to a cmd_timeout. There are occurrences where cmd_timeout never gets triggered for a long time and we encounter a kernel crash. In this patch, we track the consecutive timeouts (tx_timeout_cnt). When tx_timeout_cnt exceeds the threshold, trigger a card reset thereby avoiding a kernel crash. Signed-off-by: Ashok Nagarajan <asnagarajan@chromium.org> Signed-off-by: Paul Stewart <pstew@chromium.org> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-03-08mwifiex: fix potential out-of-boundary access to ibss rate tableBing Zhao
smatch found this error: CHECK drivers/net/wireless/mwifiex/join.c drivers/net/wireless/mwifiex/join.c:1121 mwifiex_cmd_802_11_ad_hoc_join() error: testing array offset 'i' after use. Cc: <stable@vger.kernel.org> # 3.0+ Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-03-06mwifiex: add WOWLAN supportAmitkumar Karwar
Currently 'magic-packet' and 'patterns' options in 'iw wowlan' command are supported. Appropriate packet filters for wowlan are configured in firmware based on provided patterns and/or magic-packet option. For examples, wake-on ARP request for 192.168.0.100: iw phy0 wowlan enable patterns ff:ff:ff:ff:ff:ff 20+08:06 46+c0:a8:00:64 wake-on RX packets sent from IP address 192.168.0.88: iw phy0 wowlan enable patterns 34+c0:a8:00:58 wake-on RX packets with TCP destination port 80 iw phy0 wowlan enable patterns 44+50 wake-on MagicPacket: iw phy0 wowlan enable magic-packet wake-on MagicPacket or patterns: iw phy0 wowlan enable magic-packet patterns 12+00:11:22:33:44:55 18+00:50:43:21 wake-on IPv4 multicast packets: iw phy0 wowlan enable patterns 01:00:5e wake-on IPv6 multicast packets: iw phy0 wowlan enable patterns 33:33 disable all wowlan options iw phy0 wowlan disable Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-03-06mwifiex: add "ethtool wol" command supportAmitkumar Karwar
Host sleep wakeup condition is configured using this command. Supports Wake-on: pumb For examples: wake-on any unicast packets: ethtool -s mlan0 wol u wake-on multicast/broadcast packet: ethtool -s mlan0 wol mb wake-on unicast packets and MAC events: ethtool -s mlan0 wol pu wake-on unicast/multicast/broadcast packets and MAC events: ethtool -s mlan0 wol pmbu disable all wake-on options: ethtool -s mlan0 wol d Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-22 20:13:14 +0000