- 29 6月, 2017 2 次提交
-
-
由 Colin Ian King 提交于
Trivial fix to spelling mistake in mwifiex_dbg message Signed-off-by: NColin Ian King <colin.king@canonical.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Ganapathi Bhat 提交于
When user adds a virtual interface driver will set the bss_type to the iface_type given by the user. When supplicant is started on the same interface, a call to change_virtual_intf will be triggered if if_type is not NL80211_IFTYPE_STATION. Here driver should not update it's bss_type, because bss_type is intended to indicate the original iface_type and changing the same will defeat the purpose of creating this interface. Signed-off-by: NGanapathi Bhat <gbhat@marvell.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
- 21 6月, 2017 2 次提交
-
-
由 Shawn Lin 提交于
debugfs_remove already check mwifiex_dfs_dir, so remove it. Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Caesar Wang 提交于
This patch uses WARN level is not printed by default. In some cases, some boards have always met the unused log be printed as follows. ... [23193.523182] mwifiex_pcie 0000:01:00.0: mwifiex_get_cfp: cannot find cfp by band 2 & channel=13 freq=0 [23378.633684] mwifiex_pcie 0000:01:00.0: mwifiex_get_cfp: cannot find cfp by band 2 & channel=13 freq=0 Due to we used the wifi default area was US and didn't support 12~14 channels. As Frequencies: * 2412 MHz [1] (30.0 dBm) * 2417 MHz [2] (30.0 dBm) * 2422 MHz [3] (30.0 dBm) * 2427 MHz [4] (30.0 dBm) * 2432 MHz [5] (30.0 dBm) * 2437 MHz [6] (30.0 dBm) * 2442 MHz [7] (30.0 dBm) * 2447 MHz [8] (30.0 dBm) * 2452 MHz [9] (30.0 dBm) * 2457 MHz [10] (30.0 dBm) * 2462 MHz [11] (30.0 dBm) * 2467 MHz [12] (disabled) * 2472 MHz [13] (disabled) * 2484 MHz [14] (disabled) Also, as the commit 1b499cb7 ("mwifiex: disable channel filtering feature in firmware"), it proved to be a feature to get better scan result from overlapping channel. Even there could be AP from overlapping channel (might be 12/13/14 in this case), it will be filtered depend on reg domain rules. e.g: ... if (ch->flags & IEEE80211_CHAN_DISABLED) continue; So it should not been an ERROR, use the WARN level to instead it for now. Signed-off-by: NCaesar Wang <wxt@rock-chips.com> Acked-by: NXinming Hu <huxm@marvell.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
- 16 6月, 2017 3 次提交
-
-
由 Johannes Berg 提交于
It seems like a historic accident that these return unsigned char *, and in many places that means casts are required, more often than not. Make these functions (skb_put, __skb_put and pskb_put) return void * and remove all the casts across the tree, adding a (u8 *) cast only where the unsigned char pointer was used directly, all done with the following spatch: @@ expression SKB, LEN; typedef u8; identifier fn = { skb_put, __skb_put }; @@ - *(fn(SKB, LEN)) + *(u8 *)fn(SKB, LEN) @@ expression E, SKB, LEN; identifier fn = { skb_put, __skb_put }; type T; @@ - E = ((T *)(fn(SKB, LEN))) + E = fn(SKB, LEN) which actually doesn't cover pskb_put since there are only three users overall. A handful of stragglers were converted manually, notably a macro in drivers/isdn/i4l/isdn_bsdcomp.c and, oddly enough, one of the many instances in net/bluetooth/hci_sock.c. In the former file, I also had to fix one whitespace problem spatch introduced. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Johannes Berg 提交于
A common pattern with skb_put() is to just want to memcpy() some data into the new space, introduce skb_put_data() for this. An spatch similar to the one for skb_put_zero() converts many of the places using it: @@ identifier p, p2; expression len, skb, data; type t, t2; @@ ( -p = skb_put(skb, len); +p = skb_put_data(skb, data, len); | -p = (t)skb_put(skb, len); +p = skb_put_data(skb, data, len); ) ( p2 = (t2)p; -memcpy(p2, data, len); | -memcpy(p, data, len); ) @@ type t, t2; identifier p, p2; expression skb, data; @@ t *p; ... ( -p = skb_put(skb, sizeof(t)); +p = skb_put_data(skb, data, sizeof(t)); | -p = (t *)skb_put(skb, sizeof(t)); +p = skb_put_data(skb, data, sizeof(t)); ) ( p2 = (t2)p; -memcpy(p2, data, sizeof(*p)); | -memcpy(p, data, sizeof(*p)); ) @@ expression skb, len, data; @@ -memcpy(skb_put(skb, len), data, len); +skb_put_data(skb, data, len); (again, manually post-processed to retain some comments) Reviewed-by: NStephen Hemminger <stephen@networkplumber.org> Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Johannes Berg 提交于
There were many places that my previous spatch didn't find, as pointed out by yuan linyu in various patches. The following spatch found many more and also removes the now unnecessary casts: @@ identifier p, p2; expression len; expression skb; type t, t2; @@ ( -p = skb_put(skb, len); +p = skb_put_zero(skb, len); | -p = (t)skb_put(skb, len); +p = skb_put_zero(skb, len); ) ... when != p ( p2 = (t2)p; -memset(p2, 0, len); | -memset(p, 0, len); ) @@ type t, t2; identifier p, p2; expression skb; @@ t *p; ... ( -p = skb_put(skb, sizeof(t)); +p = skb_put_zero(skb, sizeof(t)); | -p = (t *)skb_put(skb, sizeof(t)); +p = skb_put_zero(skb, sizeof(t)); ) ... when != p ( p2 = (t2)p; -memset(p2, 0, sizeof(*p)); | -memset(p, 0, sizeof(*p)); ) @@ expression skb, len; @@ -memset(skb_put(skb, len), 0, len); +skb_put_zero(skb, len); Apply it to the tree (with one manual fixup to keep the comment in vxlan.c, which spatch removed.) Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 14 6月, 2017 1 次提交
-
-
由 Johannes Berg 提交于
Use the recently introduced helper to replace the pattern of skb_put() && memset(), this transformation was done with the following spatch: @@ identifier p; expression len; expression skb; @@ -p = skb_put(skb, len); -memset(p, 0, len); +p = skb_put_zero(skb, len); Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 13 6月, 2017 2 次提交
-
-
由 Binoy Jayan 提交于
The semaphore 'async_sem' is used as a simple mutex, so it should be written as one. Semaphores are going away in the future. Signed-off-by: NBinoy Jayan <binoy.jayan@linaro.org> Reviewed-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Colin Ian King 提交于
function mwifiex_ret_pkt_aggr_ctrl can be made static as it does not need to be in global scope. Cleans up sparse warning: "symbol 'mwifiex_ret_pkt_aggr_ctrl' was not declared. Should it be static?" Signed-off-by: NColin Ian King <colin.king@canonical.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
- 08 6月, 2017 1 次提交
-
-
由 David S. Miller 提交于
Network devices can allocate reasources and private memory using netdev_ops->ndo_init(). However, the release of these resources can occur in one of two different places. Either netdev_ops->ndo_uninit() or netdev->destructor(). The decision of which operation frees the resources depends upon whether it is necessary for all netdev refs to be released before it is safe to perform the freeing. netdev_ops->ndo_uninit() presumably can occur right after the NETDEV_UNREGISTER notifier completes and the unicast and multicast address lists are flushed. netdev->destructor(), on the other hand, does not run until the netdev references all go away. Further complicating the situation is that netdev->destructor() almost universally does also a free_netdev(). This creates a problem for the logic in register_netdevice(). Because all callers of register_netdevice() manage the freeing of the netdev, and invoke free_netdev(dev) if register_netdevice() fails. If netdev_ops->ndo_init() succeeds, but something else fails inside of register_netdevice(), it does call ndo_ops->ndo_uninit(). But it is not able to invoke netdev->destructor(). This is because netdev->destructor() will do a free_netdev() and then the caller of register_netdevice() will do the same. However, this means that the resources that would normally be released by netdev->destructor() will not be. Over the years drivers have added local hacks to deal with this, by invoking their destructor parts by hand when register_netdevice() fails. Many drivers do not try to deal with this, and instead we have leaks. Let's close this hole by formalizing the distinction between what private things need to be freed up by netdev->destructor() and whether the driver needs unregister_netdevice() to perform the free_netdev(). netdev->priv_destructor() performs all actions to free up the private resources that used to be freed by netdev->destructor(), except for free_netdev(). netdev->needs_free_netdev is a boolean that indicates whether free_netdev() should be done at the end of unregister_netdevice(). Now, register_netdevice() can sanely release all resources after ndo_ops->ndo_init() succeeds, by invoking both ndo_ops->ndo_uninit() and netdev->priv_destructor(). And at the end of unregister_netdevice(), we invoke netdev->priv_destructor() and optionally call free_netdev(). Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 01 6月, 2017 2 次提交
-
-
由 Xinming Hu 提交于
AP interface need process remain-on-channel firmware event and notify cfg80211, this will be used in the listen-stage of p2p find procedure. Signed-off-by: NXinming Hu <huxm@marvell.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Shawn Lin 提交于
We don't need to check if the list is empty separately as we could use list_first_entry_or_null to cover it. Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com> Reviewed-by: NBrian Norris <briannorris@chromium.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
- 31 5月, 2017 5 次提交
-
-
由 Xinming Hu 提交于
The next packet length will be used by interface driver, to check if the next packet still could be aggregated. Signed-off-by: NXinming Hu <huxm@marvell.com> Signed-off-by: NCathy Luo <cluo@marvell.com> Signed-off-by: NGanapathi Bhat <gbhat@marvell.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Xinming Hu 提交于
Aggregation will wait for next packet until limit aggr size/number reach. Packet might be drop and also packet dequeue will be stop in some cases. This patch add timer to flush packets in aggregation list to avoid long time waiting. Signed-off-by: NXinming Hu <huxm@marvell.com> Signed-off-by: NCathy Luo <cluo@marvell.com> Signed-off-by: NGanapathi Bhat <gbhat@marvell.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Xinming Hu 提交于
Instead of using 4KB packet buffer for data transfer, new chipset have more device memory. This patch try to aggregation packets in an 16KB buffer. In this way, totally usb transaction cost will be reduced. Thoughput test on usb 2.0 show both TCP TX and UPD TX promote ~40M, from ~240M to ~280M. This feature is default disabled, and can be enabled by module parameter, like: insmod mwifiex.ko aggr_ctrl=1 Signed-off-by: NXinming Hu <huxm@marvell.com> Signed-off-by: NCathy Luo <cluo@marvell.com> Signed-off-by: NGanapathi Bhat <gbhat@marvell.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Xinming Hu 提交于
we have observed host system hang when device firmware crash, stack trace show it was an use-after-free case: previous submitted urb will be holding in usbcore, and given back to device driver when device disconnected, while the urb have been freed in usb device disconnect handler. This patch kill the holding urb before free its memory. Signed-off-by: NXinming Hu <huxm@marvell.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Xinming Hu 提交于
Usb tx aggregation feature will utilize 4-bytes bus interface header, otherwise it will be set to zero in default case. Signed-off-by: NXinming Hu <huxm@marvell.com> Signed-off-by: NCathy Luo <cluo@marvell.com> Signed-off-by: NGanapathi Bhat <gbhat@marvell.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
- 19 5月, 2017 13 次提交
-
-
由 Johan Hovold 提交于
Add the missing endianness conversions to a debug statement printing the USB device-descriptor bcdUSB field during probe. Signed-off-by: NJohan Hovold <johan@kernel.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Brian Norris 提交于
These are already handled by mwifiex_shutdown_sw() and mwifiex_reinit_sw(). Ideally, we'll kill the flag entirely eventually, as I suspect it breeds race conditions. Signed-off-by: NBrian Norris <briannorris@chromium.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Brian Norris 提交于
Signed-off-by: NBrian Norris <briannorris@chromium.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Brian Norris 提交于
These pointers are retrieved via container_of(). There's no way they are NULL. Signed-off-by: NBrian Norris <briannorris@chromium.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Brian Norris 提交于
We're using 'adapter' right before calling this. Stop being unnecessarily paranoid. Signed-off-by: NBrian Norris <briannorris@chromium.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Brian Norris 提交于
If mwifiex_shutdown_drv() is racing with another mwifiex_shutdown_drv(), we *really* have problems. Kill the lock. Signed-off-by: NBrian Norris <briannorris@chromium.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Brian Norris 提交于
When removing or resetting an mwifiex device, we don't remember to free the saved beacon buffer. Use the (somewhat misleadingly-named) mwifiex_free_priv() helper to handle this. Noticed by kmemleak during tests: echo 1 > /sys/bus/pci/devices/.../reset unreferenced object 0xffffffc09d034a00 (size 256): ... backtrace: [<ffffffc0003cdce4>] create_object+0x228/0x3c4 [<ffffffc000c0b9d8>] kmemleak_alloc+0x54/0x88 [<ffffffc0003c0848>] __kmalloc+0x1cc/0x2dc [<ffffffbffc1500c4>] mwifiex_save_curr_bcn+0x80/0x308 [mwifiex] [<ffffffbffc1516b8>] mwifiex_ret_802_11_associate+0x4ec/0x5fc [mwifiex] [<ffffffbffc15da90>] mwifiex_process_sta_cmdresp+0xaf8/0x1fa4 [mwifiex] [<ffffffbffc1411e0>] mwifiex_process_cmdresp+0x40c/0x510 [mwifiex] [<ffffffbffc13b8f4>] mwifiex_main_process+0x4a4/0xb00 [mwifiex] [<ffffffbffc13bf84>] mwifiex_main_work_queue+0x34/0x40 [mwifiex] Signed-off-by: NBrian Norris <briannorris@chromium.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Brian Norris 提交于
mwifiex_exec_next_cmd() seems to have a classic TOCTOU race, where we drop the list lock in between retrieving the next command and deleting it from the list. This potentially leaves room for someone else to also retrieve / steal this node from the list (e.g., mwifiex_cancel_all_pending_cmd()). Let's keep holding the lock while we do our 'ps_state' sanity checks. There should be no harm in continuing to hold this lock for a bit more. Noticed only by code inspection. Signed-off-by: NBrian Norris <briannorris@chromium.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Douglas Anderson 提交于
The mwifiex_11n_delba() function walked the rx_reorder_tbl_ptr without holding the lock, which was an obvious violation. Grab the lock. NOTE: we hold the lock while calling mwifiex_send_delba(). There's also several callers in 11n_rxreorder.c that hold the lock and the comments in the struct sound just like very other list/lock pair -- as if the lock should definitely be help for all operations like this. Signed-off-by: NDouglas Anderson <dianders@chromium.org> Signed-off-by: NBrian Norris <briannorris@chromium.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Douglas Anderson 提交于
Just like in the previous patch ("mwifiex: Don't release tx_ba_stream_tbl_lock while iterating"), in mwifiex_cancel_all_pending_cmd() we were itearting over a list protected by a spinlock. Again, it is not safe to release the spinlock while iterating. Don't do it. Luckily in this case there should be no need to release the spinlock. This is evidenced by: 1. The only function called while the spinlock was released was mwifiex_recycle_cmd_node() 2. Aside from atomic functions (which are safe to call), the only function called by mwifiex_recycle_cmd_node() was mwifiex_insert_cmd_to_free_q(). 3. It can be seen in mwifiex_cancel_pending_scan_cmd() that it's OK to call mwifiex_insert_cmd_to_free_q() while holding a different spinlock (scan_pending_q_lock), so in general holding a spinlock should be OK. 4. It doesn't appear that mwifiex_insert_cmd_to_free_q() has any interaction with the cmd_pending_q_lock No known bugs are fixed with this change, but as with other similar changes this could fix random list corruption. Signed-off-by: NDouglas Anderson <dianders@chromium.org> Signed-off-by: NBrian Norris <briannorris@chromium.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Douglas Anderson 提交于
Despite the macro list_for_each_entry_safe() having the word "safe" in the name, it's still not actually safe to release the list spinlock while iterating over the list. The "safe" in the macro name actually only means that it's safe to delete the current entry while iterating over the list. Releasing the spinlock while iterating over the list means that someone else could come in and adjust the list while we don't have the spinlock. If they do that it can totally mix up our iteration and fully corrupt the list. Later iterating over a corrupted list while holding a spinlock and having IRQs off can cause all sorts of hard to debug problems. As evidenced by the other call to mwifiex_11n_delete_tx_ba_stream_tbl_entry() in mwifiex_11n_delete_all_tx_ba_stream_tbl(), it's actually safe to skip the spinlock release. Let's do that. No known problems are fixed by this patch, but it could fix all sorts of weird problems and it should be very safe. Signed-off-by: NDouglas Anderson <dianders@chromium.org> Signed-off-by: NBrian Norris <briannorris@chromium.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Brian Norris 提交于
If we fail to add an interface in mwifiex_add_virtual_intf(), we might hit a BUG_ON() in the networking code, because we didn't tear things down properly. Among the problems: (a) when failing to allocate workqueues, we fail to unregister the netdev before calling free_netdev() (b) even if we do try to unregister the netdev, we're still holding the rtnl lock, so the device never properly unregistered; we'll be at state NETREG_UNREGISTERING, and then hit free_netdev()'s: BUG_ON(dev->reg_state != NETREG_UNREGISTERED); (c) we're allocating some dependent resources (e.g., DFS workqueues) after we've registered the interface; this may or may not cause problems, but it's good practice to allocate these before registering (d) we're not even trying to unwind anything when mwifiex_send_cmd() or mwifiex_sta_init_cmd() fail To fix these issues, let's: * add a stacked set of error handling labels, to keep error handling consistent and properly ordered (resolving (a) and (d)) * move the workqueue allocations before the registration (to resolve (c); also resolves (b) by avoiding error cases where we have to unregister) [Incidentally, it's pretty easy to interrupt the alloc_workqueue() in, e.g., the following: iw phy phy0 interface add mlan0 type station by sending it SIGTERM.] This bugfix covers commits like commit 7d652034 ("mwifiex: channel switch support for mwifiex"), but parts of this bug exist all the way back to the introduction of dynamic interface handling in commit 93a1df48 ("mwifiex: add cfg80211 handlers add/del_virtual_intf"). Cc: <stable@vger.kernel.org> Signed-off-by: NBrian Norris <briannorris@chromium.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Brian Norris 提交于
This code was duplicated as part of the PCIe FLR code added to this driver. Let's de-duplicate it to: * make things easier to read (mwifiex_pcie_free_buffers() now has a corresponding mwifiex_pcie_alloc_buffers()) * reduce likelihood of bugs * make error logging equally verbose * save lines of code! Also drop some of the commentary that isn't really needed. Signed-off-by: NBrian Norris <briannorris@chromium.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
- 18 5月, 2017 3 次提交
-
-
由 Brian Norris 提交于
Similar to the SDIO driver, we should implement this so that we will automatically reset the device whenever there's a command timeout or similar. Signed-off-by: NBrian Norris <briannorris@chromium.org> Reviewed-by: NDmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Brian Norris 提交于
The non-atomic test + set is a little awkward here, and it technically means we might double-schedule work unnecessarily. AFAICT, this is not really a problem, since the extra "work" will be a no-op (the flag(s) will be cleared by then), but it's still an anti-pattern. Rewrite this to use the atomic test_and_set_bit() helper instead. Signed-off-by: NBrian Norris <briannorris@chromium.org> Reviewed-by: NDmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Xinming Hu 提交于
P2p client act as a station, data will be queued by DA instead of RA. This patch pass the sanity check, so that p2p client share the same data path with infrastruction station mode. Signed-off-by: NXinming Hu <huxm@marvell.com> Signed-off-by: NCathy Luo <cluo@marvell.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
- 28 4月, 2017 1 次提交
-
-
由 Arend Van Spriel 提交于
Have proper request id filled in the SCHED_SCAN_RESULTS and SCHED_SCAN_STOPPED notifications toward user-space by having the driver provide it through the api. Reviewed-by: NHante Meuleman <hante.meuleman@broadcom.com> Reviewed-by: NPieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com> Reviewed-by: NFranky Lin <franky.lin@broadcom.com> Signed-off-by: NArend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 27 4月, 2017 2 次提交
-
-
由 Arend Van Spriel 提交于
For multiple scheduled scan support the driver needs to know which scheduled scan request is being stopped. Pass the request id in the .sched_scan_stop() callback. Reviewed-by: NHante Meuleman <hante.meuleman@broadcom.com> Reviewed-by: NPieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com> Reviewed-by: NFranky Lin <franky.lin@broadcom.com> Signed-off-by: NArend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Arend Van Spriel 提交于
This patch implements the idea to have multiple scheduled scan requests running concurrently. It mainly illustrates how to deal with the incoming request from user-space in terms of backward compatibility. In order to use multiple scheduled scans user-space needs to provide a flag attribute NL80211_ATTR_SCHED_SCAN_MULTI to indicate support. If not the request is treated as a legacy scan. Drivers currently supporting scheduled scan are now indicating they support a single scheduled scan request. This obsoletes WIPHY_FLAG_SUPPORTS_SCHED_SCAN. Reviewed-by: NHante Meuleman <hante.meuleman@broadcom.com> Reviewed-by: NPieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com> Reviewed-by: NFranky Lin <franky.lin@broadcom.com> Signed-off-by: NArend van Spriel <arend.vanspriel@broadcom.com> [clean up netlink destroy path to avoid allocations, code cleanups] Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 20 4月, 2017 3 次提交
-
-
由 Brian Norris 提交于
'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: NBrian Norris <briannorris@chromium.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Brian Norris 提交于
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: NBrian Norris <briannorris@chromium.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Brian Norris 提交于
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: NBrian Norris <briannorris@chromium.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-