- 19 Nov, 2016 15 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:
Xinming Hu <huxm@marvell.com> Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
-
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 authored
SDIO and PCIe drivers handle this. Let's imitate it. Signed-off-by:
-
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:
-
Brian Norris authored
Signed-off-by:
-
Brian Norris authored
The device core will not allow suspend() to race with remove(). Signed-off-by:
-
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:
-
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:
-
Shengzhen Li authored
Power save handshake with firmware might be blocked by on-going data transfer. this patch check the PS status in main process and complete previous blocked PS handshake. this patch also remove redudant check before call mwifiex_check_ps_cond function. Signed-off-by:
Cathy Luo <cluo@marvell.com> Signed-off-by:
Shengzhen Li <szli@marvell.com> Tested-by:
-
Shengzhen Li authored
We may get SLEEP event from firmware even if TXDone interrupt for last Tx packet is still pending. In this case, we may end up accessing PCIe memory for handling TXDone after power save handshake is completed. This causes kernel crash with external abort. This patch will only allow downloading sleep confirm when no tx done interrupt is pending in the hardware. Signed-off-by:
-
Rajat Jain authored
Commit ce4f6f0c ("mwifiex: add platform specific wakeup interrupt support") added WoWLAN feature only for sdio. This patch moves that code to the common module so that all the interface drivers can use it for free. It enables pcie and sdio for its use currently. Signed-off-by:
Rajat Jain <rajatja@google.com> Signed-off-by:
-
Rajat Jain authored
Introduce function mwifiex_probe_of() to parse common properties. Interface drivers get to decide whether or not the device tree node was a valid one (depending on the compatible property), Lets fill "adapter->dt_node" in mwifiex_add_card(). The function mwifiex_probe_of() is currently only a place holder with the next patch adding content to it. Signed-off-by:
-
Rajat Jain authored
Today all the interface drivers (usb/pcie/sdio) assign the adapter->dev in the register_dev() callback, although they have this piece of info well before hand. This patch makes the device structure available for mwifiex right at the beginning, so that it can be used for early initialization if needed. This is needed for subsequent patches in this patchset that intend to unify and consolidate some of the code that would otherwise have to be duplicated among the interface drivers (sdio, pcie, usb). Signed-off-by:
-
Xinming Hu authored
This patch derives device tree node from pcie bus layer framework. Device tree bindings file has been renamed(marvell-sd8xxx.txt -> marvell-8xxx.txt) to accommodate PCIe changes. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
- 18 Nov, 2016 3 commits
-
-
Brian Norris authored
The cleanup_if() callback is the inverse of init_if(). We allocate our 'card' interface structure in the probe() function, but we free it in cleanup_if(). That gives a few problems: (a) we leak this memory if probe() fails before we reach init_if() (b) we can't safely utilize 'card' after cleanup_if() -- namely, in remove() or suspend(), both of which might race with the cleanup paths in our asynchronous FW initialization path Solution: just use devm_kzalloc(), which will free this structure properly when the device is removed -- and drop the set_drvdata(..., NULL), since the driver core does this for us. This also removes the temptation to use drvdata == NULL as a hack for checking if the device has been "cleaned up." I *do* leave the set_drvdata(..., NULL) for the hacky SDIO mwifiex_recreate_adapter(), since the device core won't be able to clear that one for us. Signed-off-by: -
Amitkumar Karwar authored
Firmware may reject calibration data from host for certain OTP settings. In that case, we should continue initialisation ignoring the failure. Signed-off-by:
-
Shengzhen Li authored
This patch adds power save parameters(hs_wake_interval and hs_inactivity_timeout) in host sleep cfg cmd. Signed-off-by:
-
- 17 Nov, 2016 21 commits
-
-
Ricky Liang authored
kmemleak reports memory leak in mwifiex_save_hidden_ssid_channels(): unreferenced object 0xffffffc0a2914780 (size 192): comm "ksdioirqd/mmc2", pid 2004, jiffies 4307182506 (age 820.684s) hex dump (first 32 bytes): 00 06 47 49 4e 2d 32 67 01 03 c8 60 6c 03 01 40 ..GIN-2g...`l..@ 07 10 54 57 20 34 04 1e 64 05 24 84 03 24 95 04 ..TW 4..d.$..$.. backtrace: [<ffffffc0003375f4>] create_object+0x164/0x2b4 [<ffffffc0008e3530>] kmemleak_alloc+0x50/0x88 [<ffffffc000335120>] __kmalloc_track_caller+0x1bc/0x264 [<ffffffc00030899c>] kmemdup+0x38/0x64 [<ffffffbffc2311cc>] mwifiex_fill_new_bss_desc+0x3c/0x130 [mwifiex] [<ffffffbffc22ee9c>] mwifiex_save_curr_bcn+0x4ec/0x640 [mwifiex] [<ffffffbffc22f45c>] mwifiex_handle_event_ext_scan_report+0x1d4/0x268 [mwifiex] [<ffffffbffc2375d0>] mwifiex_process_sta_event+0x378/0x898 [mwifiex] [<ffffffbffc224dc8>] mwifiex_process_event+0x1a8/0x1e8 [mwifiex] [<ffffffbffc2228f0>] mwifiex_main_process+0x258/0x534 [mwifiex] [<ffffffbffc258858>] 0xffffffbffc258858 [<ffffffc00071ee90>] process_sdio_pending_irqs+0xf8/0x160 [<ffffffc00071efdc>] sdio_irq_thread+0x9c/0x1a4 [<ffffffc000240d08>] kthread+0xf4/0x100 [<ffffffc0002043fc>] ret_from_fork+0xc/0x50 [<ffffffffffffffff>] 0xffffffffffffffff Signed-off-by:Ricky Liang <jcliang@chromium.org> Acked-by:
-
Larry Finger authored
When there is a CRC error in the SPROM read from the device, the code attempts to handle a fallback SPROM. When this also fails, the driver returns zero rather than an error code. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> Signed-off-by:
-
Wei Yongjun authored
It is not allowed to call kfree_skb() from hardware interrupt context or with interrupts being disabled, spin_lock_irqsave() make sure always in irq disable context. So the kfree_skb() should be replaced with dev_kfree_skb_irq(). This is detected by Coccinelle semantic patch. Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
-
Arnd Bergmann authored
On x86, the cw1200 driver produces a rather silly warning about the possible use of the 'ret' variable without an initialization presumably after being confused by the architecture specific definition of WARN_ON: drivers/net/wireless/st/cw1200/wsm.c: In function ‘wsm_handle_rx’: drivers/net/wireless/st/cw1200/wsm.c:1457:9: error: ‘ret’ may be used uninitialized in this function [-Werror=maybe-uninitialized] We have already checked that 'count' is larger than 0 here, so we know that 'ret' is initialized. Changing the 'for' loop into do/while also makes this clear to the compiler. Suggested-by:
David Laight <David.Laight@ACULAB.COM> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Arnd Bergmann authored
The hostap_80211_rx() function is supposed to set up the mac addresses for four possible cases, based on two bits of input data. For some reason, gcc decides that it's possible that none of the these four cases apply and the addresses remain uninitialized: drivers/net/wireless/intersil/hostap/hostap_80211_rx.c: In function ‘hostap_80211_rx’: arch/x86/include/asm/string_32.h:77:14: warning: ‘src’ may be used uninitialized in this function [-Wmaybe-uninitialized] drivers/net/wireless/intel/ipw2x00/libipw_rx.c: In function ‘libipw_rx’: arch/x86/include/asm/string_32.h:77:14: error: ‘dst’ may be used uninitialized in this function [-Werror=maybe-uninitialized] arch/x86/include/asm/string_32.h:78:22: error: ‘*((void *)&dst+4)’ may be used uninitialized in this function [-Werror=maybe-uninitialized] This warning is clearly nonsense, but changing the last case into 'default' makes it obvious to the compiler too, which avoids the warning and probably leads to better object code too. The same code is duplicated several times in the kernel, so this patch uses the same workaround for all copies. The exact configuration was hit only very rarely in randconfig builds and I only saw it in three drivers, but I assume that all of them are potentially affected, and it's better to keep the code consistent. Signed-off-by:
-
Jiri Slaby authored
gcc 7 complains: drivers/net/wireless/intersil/p54/fwio.c: In function 'p54_scan': drivers/net/wireless/intersil/p54/fwio.c:491:4: warning: 'memset' used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size] Fix that by passing the correct size to memset. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Cc: Christian Lamparter <chunkeey@googlemail.com> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Acked-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
-
Rafał Miłecki authored
This simplifies debugging. Format %s (%u) comes from similar debugging message in brcmf_fweh_event_worker. Signed-off-by:
Rafał Miłecki <rafal@milecki.pl> Signed-off-by:
-
Prameela Rani Garnepudi authored
* Command frame vap_capabilites is modified to use for vap add, vap delete and vap update in firmware, hence new filed vap status is added. * When interface is down this frame needs to be send with vap status delete. Otherwise it is considered as wrong frame for the same interface in firmware. * vap_update status is reserved for future. Signed-off-by:
Prameela Rani Garnepudi <prameela.j04cs@gmail.com> Signed-off-by:
-
Prameela Rani Garnepudi authored
Observed crash when module is unloaded if CONFIG_RSI_DEBUGSFS is not set. Fix: Debugfs entry removal moved inside CONFIG_RSI_DEBUGSFS flag in function rsi_mac80211_detach() Memory leak found and fixed for below structures in function rsi_mac80211_detach() * channel list for each supported band * rsi debugfs info Signed-off-by: -
James Minor authored
When in AP mode, scans can be done without changing firmware to the multi-role firmware. Allow the interface to scan if forced in the scan request. Signed-off-by:
James Minor <james.minor@ni.com> Signed-off-by:
Xander Huff <xander.huff@ni.com> Reviewed-by:
Ben Shelton <ben.shelton@ni.com> Reviewed-by:
Jaeden Amero <jaeden.amero@ni.com> Signed-off-by:
-
Larry Finger authored
Since this driver was added to the kernel, the checkpatch script was modified to request that the address of the FSF not be included. Signed-off-by:
-
Larry Finger authored
Since this driver was added to the kernel, the checkpatch script was modified to request that the address of the FSF not be included. Signed-off-by:
-
Larry Finger authored
Since this driver was added to the kernel, the checkpatch script was modified to request that the address of the FSF not be included. Signed-off-by:
-
Larry Finger authored
Since this driver was added to the kernel, the checkpatch script was modified to request that the address of the FSF not be included. Signed-off-by:
-
Larry Finger authored
Since this driver was added to the kernel, the checkpatch script was modified to request that the address of the FSF not be included. Signed-off-by:
-
Larry Finger authored
Since this driver was added to the kernel, the checkpatch script was modified to request that the address of the FSF not be included. Signed-off-by:
-
Larry Finger authored
Since this driver was added to the kernel, the checkpatch script was modified to request that the address of the FSF not be included. Signed-off-by:
-
Larry Finger authored
Since this driver was added to the kernel, the checkpatch script was modified to request that the address of the FSF not be included. Signed-off-by:
-
Rajat Jain authored
Register the WLAN device as a wakeup source since it can wake the system via wake-on-wireless-lan. In an actual wowlan event, notify the PM core that we are the current wakeup source. This allows the PM core to update the wakeup attributes in /sys. This was causing wakeup issues on chromeos as the system was apparently confused about the wakeup source. Signed-off-by:
Wei-Ning Huang <wnhuang@google.com> Signed-off-by:
Wei-Ning Huang <wnhuang@chromium.org> Reviewed-by:
Eric Caruso <ejcaruso@chromium.org> Acked-by:
-
Maxim Altshul authored
This event is used by the Firmware to limit the RX BA win size for a specific link. The event handler updates the new size in the mac's sta->sta struct. BA sessions opened for that link will use the new restricted win_size. This limitation remains until a new update is received or until the link is closed. Signed-off-by:
Maxim Altshul <maxim.altshul@ti.com> Signed-off-by:
-
Maxim Altshul authored
When starting a new BA session, we must pass the win_size to the FW. To do this we take max_rx_aggregation_subframes (BA RX win size) which is stored in ieee80211_sta structure (e.g per link and not per HW) We will use the value stored per link when passing the win_size to firmware through the ACX_BA_SESSION_RX_SETUP command. Signed-off-by:
-
- 09 Nov, 2016 1 commit
-
-
Johannes Thumshirn authored
The call to krealloc() in wsm_buf_reserve() directly assigns the newly returned memory to buf->begin. This is all fine except when krealloc() failes we loose the ability to free the old memory pointed to by buf->begin. If we just create a temporary variable to assign memory to and assign the memory to it we can mitigate the memory leak. Signed-off-by:
Johannes Thumshirn <jthumshirn@suse.de> Cc: Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
