- 14 5月, 2014 4 次提交
-
-
由 Grazvydas Ignotas 提交于
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: NGrazvydas Ignotas <notasas@gmail.com> Tested-by: NPali Rohár <pali.rohar@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Grazvydas Ignotas 提交于
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: NGrazvydas Ignotas <notasas@gmail.com> Tested-by: NPali Rohár <pali.rohar@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 13 5月, 2014 4 次提交
-
-
由 David Spinadel 提交于
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: NDavid Spinadel <david.spinadel@intel.com> Reviewed-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Eliad Peller 提交于
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: NEliad Peller <eliadx.peller@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Daniel Kim 提交于
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: NArend Van Spriel <arend@broadcom.com> Signed-off-by: NDaniel Kim <dekim@broadcom.com> Signed-off-by: NArend van Spriel <arend@broadcom.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 11 5月, 2014 1 次提交
-
-
由 Emmanuel Grumbach 提交于
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: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
- 09 5月, 2014 2 次提交
-
-
由 Eliad Peller 提交于
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: NEliad Peller <eliadx.peller@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
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: NMichal Kazior <michal.kazior@tieto.com> Reported-by: NEyal Shapira <eyal@wizery.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 08 5月, 2014 12 次提交
-
-
由 Andrea Merello 提交于
CTS protection was not working properly because the HW needs RTS flag to be asserted, and it need also RTS duration field to be filled with CTS-to-self duration. This patch makes the driver to do this. Signed-off-by: NAndrea Merello <andrea.merello@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Andrea Merello 提交于
CTS protection was not working properly because the HW still need RTS flag to be asserted, and it need also RTS rate field to be set with CTS-to-self rate and RTS duration field to be filled with CTS-to-self duration. This patch makes the driver to do this. Signed-off-by: NAndrea Merello <andrea.merello@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Andrea Merello 提交于
This patch make it possible to mac80211 to know whether a frame has been received with short preamble. It simply checks for the "splcp" flag in the RX status descriptor, and eventually set RX_FLAG_SHORTPRE in mac80211 rx status structure. Signed-off-by: NAndrea Merello <andrea.merello@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Andrea Merello 提交于
This patch make it possible to mac80211 to know whether a frame has been received with short preamble. It simply checks for the "splcp" flag in the RX status descriptor, and eventually set RX_FLAG_SHORTPRE in mac80211 rx status structure. Signed-off-by: NAndrea Merello <andrea.merello@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Helmut Schaa 提交于
Add a new platform data flag "use_eeprom" that indicates that the eeprom found on the card itself should be used instead of the one present in the platform data. This allows to override the MAC address of a PCI card while preserving the eeprom data from the card itself. The default behavior is preserved. Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Avinash Patil 提交于
This patch adds support to populate HT operatation IE in TDLS setup confirm command. This is required for setting wider bandwidths for TDLS operations. Signed-off-by: NAvinash Patil <patila@marvell.com> Signed-off-by: NBing Zhao <bzhao@marvell.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Avinash Patil 提交于
This patch adds code to disable TDLS link upon reception of TDLS teardown event from peer. Teardown event can happen either because of TDLS teardown packet from peer or internal timeout configured during TDLS setup. Event is propogated to cfg80211 so that userspace application can take appropriate action. Signed-off-by: NAvinash Patil <patila@marvell.com> Signed-off-by: NBing Zhao <bzhao@marvell.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Avinash Patil 提交于
This patch adds configuration timeout for TDLS link. This is configuered at the time of TDLS link configuration. If TDLS link is inactive for more than timeout, FW will tear this link. Signed-off-by: NAvinash Patil <patila@marvell.com> Signed-off-by: NBing Zhao <bzhao@marvell.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Emmanuel Grumbach 提交于
In case RFKILL is in KILL position, the NIC will issue an interrupt straight away. This interrupt won't be sent because it is masked in the hardware. But if our interrupt service routine is called for another reason (SHARED_IRQ), then we'll look at the interrupt cause and service it. This can cause bad things if we are not ready yet. Explicitly clean the interrupt cause register to make sure we won't service anything before we are ready to. Cc: <stable@vger.kernel.org> [3.14] Reported-and-tested-by: NAlexander Monakov <amonakov@gmail.com> Reviewed-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Eyal Shapira 提交于
After fixes to the rs algorithm reenable MCS9. Signed-off-by: NEyal Shapira <eyalx.shapira@intel.com> Reviewed-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
- 07 5月, 2014 17 次提交
-
-
由 Emmanuel Grumbach 提交于
Since the declaration of iwl_mvm_fw_error_rxf_dump and iwl_mvm_fw_error_sram_dump is under ifdef CONFIG_IWLWIFI_DEBUGFS, do the same for their implementation. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Emmanuel Grumbach 提交于
This allows mac80211 to flush the Tx queues before it sends critical management frames. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Andrei Otcheretianski 提交于
Publish WIPHY_FLAG_HAS_CHANNEL_SWITCH if the fw supports newly introduced IWL_UCODE_TLV_API_CSA_FLOW. When CSA starts, save the switching vif inside mvm and during the CSA period configure fw with a new beacon after each beacon transmission in order to update the csa counters. Also, handle correctly the CSA unbind-bind flow which is triggered by mac80211 when the actual channel switch happens. Signed-off-by: NAndrei Otcheretianski <andrei.otcheretianski@intel.com> Reviewed-by: NLuciano Coelho <luciano.coelho@intel.com> Reviewed-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Eliad Peller 提交于
Some ampdu actions change queues by direct target access. Since the bus is disabled in d0i3, make sure to exit d0i3 before handling these actions. Signed-off-by: NEliad Peller <eliadx.peller@intel.com> Reviewed-by: NArik Nemtsov <arik@wizery.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Johannes Berg 提交于
When a firmware error occurs, capture the last 32 commands (which are still in memory) in the error dump debugfs file. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 David Spinadel 提交于
Currently the FW doesn't support sched scan while associated, Prevent it. Signed-off-by: NDavid Spinadel <david.spinadel@intel.com> Reviewed-by: NJohannes Berg <johannes.berg@intel.com> Reviewed-by: NLuciano Coelho <luciano.coelho@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Felix Fietkau 提交于
The SREV register in the WMAC register space does not contain the chip revision, so it needs to be passed in from the kernel. With an updated kernel, this fixes tx gain table selection. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Andy Spencer 提交于
With certain hardware combinations the poll interval is exceeded before initialization completes. Tested on a MacBookPro10,1 using a Sabrent USB-A11N USB adapter. Signed-off-by: NAndy Spencer <andy753421@ucla.edu> Acked-by: NLarry Finger <Larry.Finger@lwfinger.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Rajkumar Manoharan 提交于
This will enable AP mode to change channel width dynamically based on 20/40 intolerance report sent by associated client. Signed-off-by: NRajkumar Manoharan <rmanohar@qti.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ben Greear 提交于
A similar patch fixed crashes seen on an ath9k system when testing against a broken ath10k AP. This patch is slightly less protective, but probably will do the job and is less redundant. Signed-off-by: NBen Greear <greearb@candelatech.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 John W. Linville 提交于
Merge branch 'rfkill-gpio-cleanups' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next
-
由 Johannes Berg 提交于
This variable always tracks a constant value (256) so there's no need to have it. Removing it simplifies code generation, reducing the .text size (by about 240 bytes on x86-64.) Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Johannes Berg 提交于
The 'reset' argument is clearly a boolean, so use bool instead of u8 with 0/1 values. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Johannes Berg 提交于
If there's no LED on the system, it doesn't make a lot of sense to include close to 4k of LED-related code (mostly in mac80211), so instead of forcing LED support into the kernel, don't build iwlwifi/mac80211 LED support if there's no LED class support. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Reviewed-by: NEliadX Peller <eliad@wizery.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Eran Harary 提交于
The old code checks if hw_section_num is valid while the right thing to do is to check if section[hw_section_num].data is valid. Signed-off-by: NEran Harary <eran.harary@intel.com> Reviewed-by: NLiad Kaufman <liad.kaufman@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-
由 Eran Harary 提交于
For family 8000 products, the driver should take the MAC address from the mac_override section and only if this section is empty it should take it from the HW section. Signed-off-by: NEran Harary <eran.harary@intel.com> Reviewed-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
-