- 13 May, 2014 33 commits
-
-
Daniel Kim authored
The DISASSOC command needs to be sent to firmware when a connection loss is detected by firmware (e.g., beacon timeout). Otherwise the next connect request fails due to a lingering LINK(down) event from firmware. This patch resolves the issue by using brcmf_link_down() handler, instead of the incomplete duplicated codes. Reviewed-by: Arend Van Spriel <arend@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Daniel Kim <dekim@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Arend van Spriel authored
The driver serializes the nvram firmware file before sending it to the device. This patch enhances this to assure serialized data is properly formatted and provide warnings on syntax failures. Reviewed-by: Daniel (Deognyoun) Kim <dekim@broadcom.com> Reviewed-by: Franky Lin <frankyl@broadcom.com> Reviewed-by: Hante Meuleman <meuleman@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hante Meuleman authored
FWS is always queuing frames and using a worker for de-queueing, this is not always efficient for all bus layer. For example SDIO has an internal queue and worker making the queueing of FWS unnecessary. Make it possible to bypass the worker if fws mode is none using a bus interface configuration. For USB bus layer this configuration is set true to have fws provide queueing regardless the fws mode. Reviewed-by: Arend Van Spriel <arend@broadcom.com> Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by: Daniel (Deognyoun) Kim <dekim@broadcom.com> Signed-off-by: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hante Meuleman authored
Tracking and handling of 802.1x frames is done in two modules, it is more logical and clear to move this to dhd_linux module. Reviewed-by: Arend Van Spriel <arend@broadcom.com> Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by: Daniel (Deognyoun) Kim <dekim@broadcom.com> Signed-off-by: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Hante Meuleman authored
In tx_finalize the hdrpull is performed. For the new protocol msgbuf this is complex, because it does not use protocol headers in front of payload anymore and therefor can not determine interface index in the hdr pulll operation. Move out the hdrpull operation from tx_finalize to make msgbuf implementation easier. Reviewed-by: Arend Van Spriel <arend@broadcom.com> Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by: Daniel (Deognyoun) Kim <dekim@broadcom.com> Signed-off-by: Hante Meuleman <meuleman@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Daniel Kim authored
Currently firmware roaming support is not reported to cfg80211. This patch reports the support of firmware based roaming when it is enabled. Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by: Hante Meuleman <meuleman@broadcom.com> Reviewed-by: Arend Van Spriel <arend@broadcom.com> Signed-off-by: Daniel Kim <dekim@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Daniel Kim authored
When a BSS provides both 2.4GHz and 5GHz bands, in many cases it makes sense to choose 5GHz. Typically a 5GHz channel is less crowded and has less interference and therefore its performance will be better than a crowded 2.4 GHz channel. This patch configures 'join_pref' to induce firmware to preferably select 5GHz BSS. Reviewed-by: Arend Van Spriel <arend@broadcom.com> Signed-off-by: Daniel Kim <dekim@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Oleksij Rempel authored
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Oleksij Rempel authored
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Oleksij Rempel authored
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Oleksij Rempel authored
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Oleksij Rempel authored
and use it. This move need changes in both drivers. Signed-off-by: Oleksij Rempel <linux@rempel-privat.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Oleksij Rempel authored
to fix compile errors Signed-off-by: Oleksij Rempel <linux@rempel-privat.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Oleksij Rempel authored
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Oleksij Rempel authored
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Oleksij Rempel authored
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Oleksij Rempel authored
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rafał Miłecki authored
This adds choice submenu "Supported bus types" as two simple bool configs would allow user to compile b43 without any bus support (prety useless). Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rafał Miłecki authored
Users of new (BCMA based) wireless chipsets may not want to enable SSB. This is hopefully the last code patch for dropping SSB dependency. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ondrej Zary authored
The check of ezusb_firmware_download() return value (added by commit 488ec878) is broken because ezusb_firmware_download() returns 1 on success. This causes the driver not to work with the following error: orinoco_usb: probe of 3-3:1.0 failed with error -14 Check the return value only for negative values. This fix should be applied to -stable kernels too. Signed-off-by: Ondrej Zary <linux@rainbow-software.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Zefir Kurtisi authored
Systems with multiple DFS channel detectors need to track timestamp of previous pulse per instance to display the correct pulse interval. Since the interval value is used for debug printing only, this is a non-functional modification. Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Helmut Schaa authored
Originally Helmut posted a v2 of the "ath9k: Allow platform override without EEPROM override", but I had prematurely commited the original as commit 552a5157. This commit restores the tree to what Helmut intended with his v2 submission. -- JWL Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Adam Lee authored
The msi module parameter offers an option to enable or disable MSI interrupts mode, for debugging and workaround(in case) convenience. Signed-off-by: Adam Lee <adam.lee@canonical.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Adam Lee authored
The msi module parameter offers an option to enable or disable MSI interrupts mode. For now, some users report RTL8188EE works only with MSI on their certain platforms, some others report it works only without MSI, this parameter will help. Signed-off-by: Adam Lee <adam.lee@canonical.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Adam Lee authored
This makes MSI support a module parameter, for debugging and workaround convenience. Signed-off-by: Adam Lee <adam.lee@canonical.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Grazvydas Ignotas authored
ieee80211_beacon_loss() is only to be called in managed mode, but the firmware may send the sync timeout event at any time, so do a check before calling. Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Tested-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Grazvydas Ignotas authored
The join arguments are mixed up, passing beacon_interval instead of channel and channel instead of beacon_interval. Fix them. Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Tested-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Grazvydas Ignotas authored
Fix the WARN below by not calling ieee80211_nullfunc_get() in IBSS mode, but setting up empty template the same way wl12xx driver does. WARNING: CPU: 0 PID: 914 at net/mac80211/tx.c:2750 ieee80211_nullfunc_get+0xc0/0xd0 [mac80211]() Modules linked in: wl1251_sdio wl1251 mac80211 cfg80211 ... [<c00439c0>] (warn_slowpath_null) [<bf0bdfdc>] (ieee80211_nullfunc_get [mac80211]) [<bf134774>] (wl1251_op_bss_info_changed [wl1251]) [<bf099e14>] (ieee80211_bss_info_change_notify [mac80211]) ... Also perform join command regardless of bss_type as that seems to be required for proper operation. Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Tested-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Grazvydas Ignotas authored
This reverts commit b90a1165. That commit (or rather, hack) triggers a scary WARN in IBSS (ad-hoc) mode. Steps to reproduce: ifconfig wlan0 down iwconfig wlan0 mode ad-hoc ifconfig wlan0 up ------------[ cut here ]------------ WARNING: CPU: 0 PID: 905 at kernel/workqueue.c:1400 __queue_work+0x21c/0x2f4() Modules linked in: wl1251_sdio wl1251 mac80211 cfg80211 CPU: 0 PID: 905 Comm: ifconfig Not tainted 3.15.0-rc2#233 [<c0015f38>] (unwind_backtrace) from [<c0012938>] [<c0012938>] (show_stack) from [<c05d4034>] [<c05d4034>] (dump_stack) from [<c0043984>] [<c0043984>] (warn_slowpath_common) from [<c00439c0>] [<c00439c0>] (warn_slowpath_null) from [<c005b6c8>] [<c005b6c8>] (__queue_work) from [<c005b820>] [<c005b820>] (queue_work_on) from [<bf134ac0>] [<bf134ac0>] (wl1251_op_config [wl1251]) [<bf099a70>] (ieee80211_hw_config [mac80211]) ... This happens because ieee80211_connection_loss() is not expected to be called in IBSS mode (mac80211 ends up queuing uninitialized work in that case). Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Tested-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
David Spinadel authored
Prevent sched scan while not idle (including during association or in AP mode) instead of while associated only. This fixes my previous commit which was incomplete: commit bd5e4744 Author: David Spinadel <david.spinadel@intel.com> Date: Thu Apr 24 13:15:29 2014 +0300 iwlwifi: mvm: do no sched scan while associated Currently the FW doesn't support sched scan while associated, Prevent it. Signed-off-by: David Spinadel <david.spinadel@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
Eliad Peller authored
tail should be equal to the last valid index, so decrease it by one. This error causes in "a gap" in some cases (as well as some possible out-of-bound write), finally resulting in ucode assertion. Signed-off-by: Eliad Peller <eliadx.peller@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
- 12 May, 2014 2 commits
-
-
Daniel Kim authored
Fix iovar 'bw_cap' set command failure introduced by commit ff3b0fba6f25555ef59c55d138a467d0f81d82d7 Author: Arend van Spriel <arend@broadcom.com> Date: Sat Mar 15 12:00:57 2014 +0100 brcmfmac: fallback to mimo_bw_cap for older firmwares This resulted in disabling 20MHz operation in the firmware. Reviewed-by: Arend Van Spriel <arend@broadcom.com> Signed-off-by: Daniel Kim <dekim@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
-
- 11 May, 2014 1 commit
-
-
Emmanuel Grumbach authored
There was a deadlock in monitor mode when we were setting the channel if the channel was not 1. ====================================================== [ INFO: possible circular locking dependency detected ] 3.14.3 #4 Not tainted ------------------------------------------------------- iw/3323 is trying to acquire lock: (&local->chanctx_mtx){+.+.+.}, at: [<ffffffffa062e2f2>] ieee80211_vif_release_channel+0x42/0xb0 [mac80211] but task is already holding lock: (&local->iflist_mtx){+.+...}, at: [<ffffffffa0609e0a>] ieee80211_set_monitor_channel+0x5a/0x1b0 [mac80211] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&local->iflist_mtx){+.+...}: [<ffffffff810d95bb>] __lock_acquire+0xb3b/0x13b0 [<ffffffff810d9ee0>] lock_acquire+0xb0/0x1f0 [<ffffffff817eb9c8>] mutex_lock_nested+0x78/0x4f0 [<ffffffffa06225cf>] ieee80211_iterate_active_interfaces+0x2f/0x60 [mac80211] [<ffffffffa0518189>] iwl_mvm_recalc_multicast+0x49/0xa0 [iwlmvm] [<ffffffffa051822e>] iwl_mvm_configure_filter+0x4e/0x70 [iwlmvm] [<ffffffffa05e6d43>] ieee80211_configure_filter+0x153/0x5f0 [mac80211] [<ffffffffa05e71f5>] ieee80211_reconfig_filter+0x15/0x20 [mac80211] [snip] -> #1 (&mvm->mutex){+.+.+.}: [<ffffffff810d95bb>] __lock_acquire+0xb3b/0x13b0 [<ffffffff810d9ee0>] lock_acquire+0xb0/0x1f0 [<ffffffff817eb9c8>] mutex_lock_nested+0x78/0x4f0 [<ffffffffa0517246>] iwl_mvm_add_chanctx+0x56/0xe0 [iwlmvm] [<ffffffffa062ca1e>] ieee80211_new_chanctx+0x13e/0x410 [mac80211] [<ffffffffa062d953>] ieee80211_vif_use_channel+0x1c3/0x5a0 [mac80211] [<ffffffffa06035ab>] ieee80211_add_virtual_monitor+0x1ab/0x6b0 [mac80211] [<ffffffffa06052ea>] ieee80211_do_open+0xe6a/0x15a0 [mac80211] [<ffffffffa0605a79>] ieee80211_open+0x59/0x60 [mac80211] [snip] -> #0 (&local->chanctx_mtx){+.+.+.}: [<ffffffff810d6cb7>] check_prevs_add+0x977/0x980 [<ffffffff810d95bb>] __lock_acquire+0xb3b/0x13b0 [<ffffffff810d9ee0>] lock_acquire+0xb0/0x1f0 [<ffffffff817eb9c8>] mutex_lock_nested+0x78/0x4f0 [<ffffffffa062e2f2>] ieee80211_vif_release_channel+0x42/0xb0 [mac80211] [<ffffffffa0609ec3>] ieee80211_set_monitor_channel+0x113/0x1b0 [mac80211] [<ffffffffa058fb37>] cfg80211_set_monitor_channel+0x77/0x2b0 [cfg80211] [<ffffffffa056e0b2>] __nl80211_set_channel+0x122/0x140 [cfg80211] [<ffffffffa0581374>] nl80211_set_wiphy+0x284/0xaf0 [cfg80211] [snip] other info that might help us debug this: Chain exists of: &local->chanctx_mtx --> &mvm->mutex --> &local->iflist_mtx Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&local->iflist_mtx); lock(&mvm->mutex); lock(&local->iflist_mtx); lock(&local->chanctx_mtx); *** DEADLOCK *** This deadlock actually occurs: INFO: task iw:3323 blocked for more than 120 seconds. Not tainted 3.14.3 #4 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. iw D ffff8800c8afcd80 4192 3323 3322 0x00000000 ffff880078fdb7e0 0000000000000046 ffff8800c8afcd80 ffff880078fdbfd8 00000000001d5540 00000000001d5540 ffff8801141b0000 ffff8800c8afcd80 ffff880078ff9e38 ffff880078ff9e38 ffff880078ff9e40 0000000000000246 Call Trace: [<ffffffff817ea841>] schedule_preempt_disabled+0x31/0x80 [<ffffffff817ebaed>] mutex_lock_nested+0x19d/0x4f0 [<ffffffffa06225cf>] ? ieee80211_iterate_active_interfaces+0x2f/0x60 [mac80211] [<ffffffffa06225cf>] ? ieee80211_iterate_active_interfaces+0x2f/0x60 [mac80211] [<ffffffffa052a680>] ? iwl_mvm_power_mac_update_mode+0xc0/0xc0 [iwlmvm] [<ffffffffa06225cf>] ieee80211_iterate_active_interfaces+0x2f/0x60 [mac80211] [<ffffffffa0529357>] _iwl_mvm_power_update_binding+0x27/0x80 [iwlmvm] [<ffffffffa0516eb1>] iwl_mvm_unassign_vif_chanctx+0x81/0xc0 [iwlmvm] [<ffffffffa062d3ff>] __ieee80211_vif_release_channel+0xdf/0x470 [mac80211] [<ffffffffa062e2fa>] ieee80211_vif_release_channel+0x4a/0xb0 [mac80211] [<ffffffffa0609ec3>] ieee80211_set_monitor_channel+0x113/0x1b0 [mac80211] [<ffffffffa058fb37>] cfg80211_set_monitor_channel+0x77/0x2b0 [cfg80211] [<ffffffffa056e0b2>] __nl80211_set_channel+0x122/0x140 [cfg80211] [<ffffffffa0581374>] nl80211_set_wiphy+0x284/0xaf0 [cfg80211] This fixes https://bugzilla.kernel.org/show_bug.cgi?id=75541 Cc: <stable@vger.kernel.org> [3.13+] Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
-
- 09 May, 2014 2 commits
-
-
Eliad Peller authored
If sdata doesn't have a valid dev (e.g. in case of monitor vif), the vif_name field was initialized with (a length of) some short string, but later was set to a different, potentially larger one. This resulted in out-of-bounds write, which usually appeared as garbage in the trace log. Simply trace sdata->name, as it should always have the correct name for both cases. Signed-off-by: Eliad Peller <eliadx.peller@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
There are two (related) issues with this. One case, reported by Michal, is related to hostap: it unsets the 20/40 capability bit for stations that associate when it's in 20 MHz mode. The other case, reported by Eyal, is that some APs like Netgear R6300v2 and probably others based on the BCM4360 chipset can be configured for doing VHT at 20Mhz. In this case the beacon has a VHT IE but the HT cap indicates transmitter only support 20Mhz. In both of these cases, we currently avoid VHT and use only HT this means we can't use the highest rates (MCS8), so fixing this leads to throughput improvements. Reported-by: Michal Kazior <michal.kazior@tieto.com> Reported-by: Eyal Shapira <eyal@wizery.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 08 May, 2014 2 commits
-