- 25 Jun, 2012 1 commit
-
-
Felix Fietkau authored
commit 7a532fe7 ath9k_hw: fix interpretation of the rx KeyMiss flag This commit used the rx key miss indication to detect packets that were passed from the hardware without being decrypted, however it seems that this bit is not only undefined in the static WEP case, but also for dynamically allocated WEP keys. This caused a regression when using WEP-LEAP. This patch fixes the regression by keeping track of which key indexes refer to CCMP keys and only using the key miss indication for those. Reported-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Cc: stable@vger.kernel.org Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- 22 Jun, 2012 5 commits
-
-
Amitkumar Karwar authored
skb allocated during initialisation is reused for receiving commands/events by USB interface. We miss to reset skb->data in failure cases. This patch takes care of it. Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
Kiran Divekar <dkiran@marvell.com> Signed-off-by:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
-
Amitkumar Karwar authored
This patch ensures uniformity in event skb sent by interface code (USB/PCIe/SDIO) which automatically fixes following bugs. 1) For USB interface, same buffer is reused for receiving cmd and events from firmware. While handling events, we perform skb_pull(skb, 4) to remove event header. Corresponding skb_push() call is missing while submitting the buffer. 2) For PCIe interface, event skb is passed with event header. Recently added uAP events EVENT_UAP_STA_ASSOC, EVENT_UAP_STA_DEAUTH will not work for PCIe, as they assume event skb points to event body. Signed-off-by:
-
Stone Piao authored
After association, STA will go through eapol handshake with WPS enabled AP. It's observed that WPS handshake fails with some 11n AP. The reason for the failure is that the eapol packet is sent via 11n frame aggregation. The eapol packet should be sent directly without 11n aggregation. This patch fixes the problem by adding WPS session control while dequeuing Tx packets for transmission. Cc: "3.4.y" <stable@vger.kernel.org> Signed-off-by:
Stone Piao <piaoyun@marvell.com> Signed-off-by:
Avinash Patil <patila@marvell.com> Signed-off-by:
-
Stone Piao authored
Currently we check the sequence number of last packet received against start_win. If a sequence hole is detected, start_win is updated to next sequence number. Since the rx sequence number is initialized to 0, a corner case exists when BA setup happens immediately after association. As 0 is a valid sequence number, start_win gets increased to 1 incorrectly. This causes the first packet with sequence number 0 being dropped. Initialize rx sequence number as 0xffff and skip adjusting start_win if the sequence number remains 0xffff. The sequence number will be updated once the first packet is received. Cc: "3.0.y, 3.1.y, 3.2.y, 3.3.y, 3.4.y" <stable@vger.kernel.org> Signed-off-by:
-
-
- 21 Jun, 2012 1 commit
-
-
Eliad Peller authored
ieee80211_set_disassoc() clears ifmgd->bssid before building DELBA frames, resulting in frames with invalid bssid ("00:00:00:00:00:00"). Fix it by clearing ifmgd->bssid only after building all the needed frames. After this change, we no longer need to save the bssid (before clearing it), so remove the local array. Reported-by:Ido Yariv <ido@wizery.com> Cc: stable@vger.kernel.org Signed-off-by:
Eliad Peller <eliad@wizery.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
- 20 Jun, 2012 6 commits
-
-
Rajkumar Manoharan authored
After the change "mac80211: remove spurious BSSID change flag", BSS_CHANGED_BSSID will not be passed on association or IBSS status changes. So it could be better to program bssid on ASSOC or IBSS change notification. Not doing so, is affecting the packet transmission. Cc: stable@vger.kernel.org [3.4+] Reported-by:
Michael Leun <lkml20120218@newton.leun.net> Signed-off-by:
Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by:
-
Johannes Berg authored
When debugging is disabled, the event log functions aren't functional in the way that the debugfs file expects. This leads to the debugfs access crashing. Since the event log functions aren't functional then, remove the debugfs file when CONFIG_IWLWIFI_DEBUG is not set. Cc: stable@kernel.org Reported-by:
Lekensteyn <lekensteyn@gmail.com> Reviewed-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Mohammed Shafi Shajakhan authored
"ath9k: Fix softlockup in AR9485" with commit id 64bc1239 fixed the reported issue, yet its better to avoid the possible infinite loop in ar9003_get_pll_sqsum_dvc by having a timeout as suggested by ath9k maintainers. http://www.spinics.net/lists/linux-wireless/msg92126.html. Based on my testing PLL's locking measurement is done in ~200us (2 iterations). Cc: stable@vger.kernel.org Cc: Rolf Offermanns <rolf.offermanns@gmx.net> Cc: Sujith Manoharan <c_manoha@qca.qualcomm.com> Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com> Signed-off-by:
Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by:
-
Grazvydas Ignotas authored
This patch fixes two memory leaks in the SPI initialization code. Patch based on old maemo patch by: Yuri Ershov <ext-yuri.ershov@nokia.com> Signed-off-by:
Grazvydas Ignotas <notasas@gmail.com> Signed-off-by:
-
Grazvydas Ignotas authored
Always report beacon loss to the stack, not only when in powersave state. This is because there's possibility that the driver disables PSM before it handles old BSS_LOSE_EVENT, so beacon loss has to be reported. Patch based on old maemo patch by: Janne Ylalehto <janne.ylalehto@nokia.com> Juuso Oikarinen <juuso.oikarinen@nokia.com> Luciano Coelho <luciano.coelho@nokia.com> Yuri Ershov <ext-yuri.ershov@nokia.com> Signed-off-by:
-
Grazvydas Ignotas authored
Cast MSB part of current TSF to u64 to prevent loss of most significant bits. MSB should also be shifted by 32. Patch based on old maemo patch by: Yuri Kululin <ext-yuri.kululin@nokia.com> Yuri Ershov <ext-yuri.ershov@nokia.com> Signed-off-by:
-
- 19 Jun, 2012 8 commits
-
-
-
Bing Zhao authored
add_virtual_intf() needs to return an ERR_PTR(), instead of NULL, on errors, otherwise cfg80211 will crash. Reported-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
Dan Carpenter authored
"qual" used to be declared on the stack, but then in 998a5a7d ("airo: reduce stack memory footprint") we made it dynamically allocated. Unfortunately the memcpy() here was missed and it's still copying stack memory instead of the data that we want. In other words, "&qual" should be "qual". Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Avinash Patil authored
When running heavy traffic we stop the tx queue if the pending packet count reaches certain threshold. Later, the tx queue should be woken up as soon as the packet count falls below the threshold. Current code wakes TX queue up on STA interface only. Removing the check for STA interface will allow both STA and AP interfaces to resume transmit when tx_pending count becomes low. Signed-off-by:
-
Bob Copeland authored
spin_unlock_bh(&txq->lock) already disables softirqs so we don't want to do it here. Fixes smatch warnings: drivers/net/wireless/ath/ath5k/base.c:1048 ath5k_drain_tx_buffs() error: double lock 'bottom_half:' drivers/net/wireless/ath/ath5k/base.c:1056 ath5k_drain_tx_buffs() error: double unlock 'bottom_half:' Reported-by:
Bob Copeland <me@bobcopeland.com> Signed-off-by:
-
Felix Fietkau authored
After setup_frame_info has been called, only info->control.rates is still valid, other control fields have been overwritten by the ath_frame_info data. Move the access to info->control.vif for checking short preamble to setup_frame_info before it gets overwritten. This regression was introduced in commit d47a61aa "ath9k: Fix multi-VIF BSS handling" Signed-off-by:
Thomas Hühn <thomas@net.t-labs.tu-berlin.de> Acked-by:
Sujith Manoharan <c_manoha@qca.qualcomm.com> Cc: stable@vger.kernel.org [3.4] Signed-off-by:
-
Felix Fietkau authored
The rate pointer variable for a rate series is used in a loop before it is initialized. This went unnoticed because it was used earlier for the RTS/CTS rate. This bug can lead to the wrong PHY type being passed to the duration calculation function. Signed-off-by:
-
Andrei Emeltchenko authored
Vendor-specific events shall be processed in driver and not sent to bluetooth stack where they screw up HCI command countings. Signed-off-by:
Andrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by:
Gustavo Padovan <gustavo.padovan@collabora.co.uk>
-
- 14 Jun, 2012 1 commit
-
-
Vishal Agarwal authored
HCI_Disconnect should only be sent after connection is established. If connection is not yet established and HCI_Disconnect is called then disconnection complete will be received with a handle which does not exist and hence this event will be ignored. But as mgmt.c will not receive this event, its variable for pending command is not cleared.This will result in future Disconnect commands for that BD Address to be blocked with error busy. Signed-off-by:
Vishal Agarwal <vishal.agarwal@stericsson.com> Acked-by:
Johan Hedberg <johan.hedberg@intel.com> Signed-off-by:
-
- 13 Jun, 2012 5 commits
-
-
Mohammed Shafi Shajakhan authored
steps to recreate: load latest ath9k driver with AR9485 stop the network-manager and wpa_supplicant bring the interface up Call Trace: [<ffffffffa0517490>] ? ath_hw_check+0xe0/0xe0 [ath9k] [<ffffffff812cd1e8>] __const_udelay+0x28/0x30 [<ffffffffa03bae7a>] ar9003_get_pll_sqsum_dvc+0x4a/0x80 [ath9k_hw] [<ffffffffa05174eb>] ath_hw_pll_work+0x5b/0xe0 [ath9k] [<ffffffff810744fe>] process_one_work+0x11e/0x470 [<ffffffff8107530f>] worker_thread+0x15f/0x360 [<ffffffff810751b0>] ? manage_workers+0x230/0x230 [<ffffffff81079af3>] kthread+0x93/0xa0 [<ffffffff815fd3a4>] kernel_thread_helper+0x4/0x10 [<ffffffff81079a60>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff815fd3a0>] ? gs_change+0x13/0x13 ensure that the PLL-WAR for AR9485/AR9340 is executed only if the STA is associated (or) IBSS/AP mode had started beaconing. Ideally this WAR is needed to recover from some rare beacon stuck during stress testing. Before the STA is associated/IBSS had started beaconing, PLL4(0x1618c) always seem to have zero even though we had configured PLL3(0x16188) to query about PLL's locking status. When we keep on polling infinitely PLL4's 8th bit(ie check for PLL locking measurements is done), machine hangs due to softlockup. fixes https://bugzilla.redhat.com/show_bug.cgi?id=811142Reported-by:
Rolf Offermanns <rolf.offermanns@gmx.net> Cc: stable@vger.kernel.org [3.0+] Tested-by:
-
-
David Spinadel authored
Stop connection monitor poll during disassociation. This clears the polling flags and if a scan was deferred it will be run. Without this fix, if a scan was deferred due to connection monitoring while disassociation happens, this scan blocks further scan requests until interface down/up which causes problems connecting to another AP. Signed-off-by:
David Spinadel <david.spinadel@intel.com> Signed-off-by:
-
Eliad Peller authored
Otherwise, we might call the driver callback before the interface was uploaded. Solves the following warning: WARNING: at net/mac80211/driver-ops.h:12 ieee80211_set_bitrate_mask+0xbc/0x18c [mac80211]() wlan0: Failed check-sdata-in-driver check, flags: 0x0 Modules linked in: wlcore_sdio wl12xx wl18xx wlcore mac80211 cfg80211 [last unloaded: cfg80211] [<c001b964>] (unwind_backtrace+0x0/0x12c) from [<c0495550>] (dump_stack+0x20/0x24) [<c0495550>] (dump_stack+0x20/0x24) from [<c003ee28>] (warn_slowpath_common+0x5c/0x74) [<c003ee28>] (warn_slowpath_common+0x5c/0x74) from [<c003eefc>] (warn_slowpath_fmt+0x40/0x48) [<c003eefc>] (warn_slowpath_fmt+0x40/0x48) from [<bf5c1ad0>] (ieee80211_set_bitrate_mask+0xbc/0x18c [mac80211]) [<bf5c1ad0>] (ieee80211_set_bitrate_mask+0xbc/0x18c [mac80211]) from [<bf575960>] (nl80211_set_tx_bitrate_mask+0x350/0x358 [cfg80211]) [<bf575960>] (nl80211_set_tx_bitrate_mask+0x350/0x358 [cfg80211]) from [<c03e9e94>] (genl_rcv_msg+0x1a8/0x1e8) [<c03e9e94>] (genl_rcv_msg+0x1a8/0x1e8) from [<c03e9164>] (netlink_rcv_skb+0x5c/0xc0) [<c03e9164>] (netlink_rcv_skb+0x5c/0xc0) from [<c03e9ce0>] (genl_rcv+0x28/0x34) [<c03e9ce0>] (genl_rcv+0x28/0x34) from [<c03e8e74>] (netlink_unicast+0x158/0x234) [<c03e8e74>] (netlink_unicast+0x158/0x234) from [<c03e93e0>] (netlink_sendmsg+0x218/0x298) [<c03e93e0>] (netlink_sendmsg+0x218/0x298) from [<c03b4e5c>] (sock_sendmsg+0xa4/0xc0) [<c03b4e5c>] (sock_sendmsg+0xa4/0xc0) from [<c03b5af4>] (__sys_sendmsg+0x1d8/0x254) [<c03b5af4>] (__sys_sendmsg+0x1d8/0x254) from [<c03b5ca8>] (sys_sendmsg+0x4c/0x70) [<c03b5ca8>] (sys_sendmsg+0x4c/0x70) from [<c0013980>] (ret_fast_syscall+0x0/0x3c) Note that calling the driver can also result in undefined behaviour since it doesn't have to deal with calls while down. Signed-off-by:
-
Eliad Peller authored
reg_timeout_work() calls restore_regulatory_settings() which takes cfg80211_mutex. reg_set_request_processed() already holds cfg80211_mutex before calling cancel_delayed_work_sync(reg_timeout), so it might deadlock. Call the async cancel_delayed_work instead, in order to avoid the potential deadlock. This is the relevant lockdep warning: cfg80211: Calling CRDA for country: XX ====================================================== [ INFO: possible circular locking dependency detected ] 3.4.0-rc5-wl+ #26 Not tainted ------------------------------------------------------- kworker/0:2/1391 is trying to acquire lock: (cfg80211_mutex){+.+.+.}, at: [<bf28ae00>] restore_regulatory_settings+0x34/0x418 [cfg80211] but task is already holding lock: ((reg_timeout).work){+.+...}, at: [<c0059e94>] process_one_work+0x1f0/0x480 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 ((reg_timeout).work){+.+...}: [<c008fd44>] validate_chain+0xb94/0x10f0 [<c0090b68>] __lock_acquire+0x8c8/0x9b0 [<c0090d40>] lock_acquire+0xf0/0x114 [<c005b600>] wait_on_work+0x4c/0x154 [<c005c000>] __cancel_work_timer+0xd4/0x11c [<c005c064>] cancel_delayed_work_sync+0x1c/0x20 [<bf28b274>] reg_set_request_processed+0x50/0x78 [cfg80211] [<bf28bd84>] set_regdom+0x550/0x600 [cfg80211] [<bf294cd8>] nl80211_set_reg+0x218/0x258 [cfg80211] [<c03c7738>] genl_rcv_msg+0x1a8/0x1e8 [<c03c6a00>] netlink_rcv_skb+0x5c/0xc0 [<c03c7584>] genl_rcv+0x28/0x34 [<c03c6720>] netlink_unicast+0x15c/0x228 [<c03c6c7c>] netlink_sendmsg+0x218/0x298 [<c03933c8>] sock_sendmsg+0xa4/0xc0 [<c039406c>] __sys_sendmsg+0x1e4/0x268 [<c0394228>] sys_sendmsg+0x4c/0x70 [<c0013840>] ret_fast_syscall+0x0/0x3c -> #1 (reg_mutex){+.+.+.}: [<c008fd44>] validate_chain+0xb94/0x10f0 [<c0090b68>] __lock_acquire+0x8c8/0x9b0 [<c0090d40>] lock_acquire+0xf0/0x114 [<c04734dc>] mutex_lock_nested+0x48/0x320 [<bf28b2cc>] reg_todo+0x30/0x538 [cfg80211] [<c0059f44>] process_one_work+0x2a0/0x480 [<c005a4b4>] worker_thread+0x1bc/0x2bc [<c0061148>] kthread+0x98/0xa4 [<c0014af4>] kernel_thread_exit+0x0/0x8 -> #0 (cfg80211_mutex){+.+.+.}: [<c008ed58>] print_circular_bug+0x68/0x2cc [<c008fb28>] validate_chain+0x978/0x10f0 [<c0090b68>] __lock_acquire+0x8c8/0x9b0 [<c0090d40>] lock_acquire+0xf0/0x114 [<c04734dc>] mutex_lock_nested+0x48/0x320 [<bf28ae00>] restore_regulatory_settings+0x34/0x418 [cfg80211] [<bf28b200>] reg_timeout_work+0x1c/0x20 [cfg80211] [<c0059f44>] process_one_work+0x2a0/0x480 [<c005a4b4>] worker_thread+0x1bc/0x2bc [<c0061148>] kthread+0x98/0xa4 [<c0014af4>] kernel_thread_exit+0x0/0x8 other info that might help us debug this: Chain exists of: cfg80211_mutex --> reg_mutex --> (reg_timeout).work Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((reg_timeout).work); lock(reg_mutex); lock((reg_timeout).work); lock(cfg80211_mutex); *** DEADLOCK *** 2 locks held by kworker/0:2/1391: #0: (events){.+.+.+}, at: [<c0059e94>] process_one_work+0x1f0/0x480 #1: ((reg_timeout).work){+.+...}, at: [<c0059e94>] process_one_work+0x1f0/0x480 stack backtrace: [<c001b928>] (unwind_backtrace+0x0/0x12c) from [<c0471d3c>] (dump_stack+0x20/0x24) [<c0471d3c>] (dump_stack+0x20/0x24) from [<c008ef70>] (print_circular_bug+0x280/0x2cc) [<c008ef70>] (print_circular_bug+0x280/0x2cc) from [<c008fb28>] (validate_chain+0x978/0x10f0) [<c008fb28>] (validate_chain+0x978/0x10f0) from [<c0090b68>] (__lock_acquire+0x8c8/0x9b0) [<c0090b68>] (__lock_acquire+0x8c8/0x9b0) from [<c0090d40>] (lock_acquire+0xf0/0x114) [<c0090d40>] (lock_acquire+0xf0/0x114) from [<c04734dc>] (mutex_lock_nested+0x48/0x320) [<c04734dc>] (mutex_lock_nested+0x48/0x320) from [<bf28ae00>] (restore_regulatory_settings+0x34/0x418 [cfg80211]) [<bf28ae00>] (restore_regulatory_settings+0x34/0x418 [cfg80211]) from [<bf28b200>] (reg_timeout_work+0x1c/0x20 [cfg80211]) [<bf28b200>] (reg_timeout_work+0x1c/0x20 [cfg80211]) from [<c0059f44>] (process_one_work+0x2a0/0x480) [<c0059f44>] (process_one_work+0x2a0/0x480) from [<c005a4b4>] (worker_thread+0x1bc/0x2bc) [<c005a4b4>] (worker_thread+0x1bc/0x2bc) from [<c0061148>] (kthread+0x98/0xa4) [<c0061148>] (kthread+0x98/0xa4) from [<c0014af4>] (kernel_thread_exit+0x0/0x8) cfg80211: Calling CRDA to update world regulatory domain cfg80211: World regulatory domain updated: cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm) cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Cc: stable@kernel.org Signed-off-by:
-
- 12 Jun, 2012 4 commits
-
-
Avinash Patil authored
Test procedure: 1. Start AP with security setting (e.g. WPA2) 2. Stop AP 3. Start AP with open security Here it's observed that privacy is enabled in beacons and probe responses. This patch fixes it by checking the privacy parameter from cfg80211_ap_settings. If privacy is not set in cfg80211_ap_settings, set open authentication and no encryption in FW. Signed-off-by:
-
Ashok Nagarajan authored
Add a few kernel-doc descriptions that were missed during mesh development. Reported-by:
Randy Dunlap <rdunlap@xenotime.net> Signed-off-by:
Ashok Nagarajan <ashok@cozybit.com> Acked-by:
-
Giancarlo Formicuccia authored
Add support for the AR3012 chip found on the Toshiba Sallite M840-1000-XQ. usb-devices shows: T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0930 ProdID=0219 Rev=00.02 S: Manufacturer=Atheros Communications S: Product=Bluetooth USB Host Controller S: SerialNumber=Alaska Day 2006 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Signed-off-by:
Giancarlo Formicuccia <giancarlo.formicuccia@gmail.com> Signed-off-by:
-
Szymon Janc authored
If remote device sends bogus RFC option with invalid length, undefined options values are used. Fix this by using defaults when remote misbehaves. This also fixes the following warning reported by gcc 4.7.0: net/bluetooth/l2cap_core.c: In function 'l2cap_config_rsp': net/bluetooth/l2cap_core.c:3302:13: warning: 'rfc.max_pdu_size' may be used uninitialized in this function [-Wmaybe-uninitialized] net/bluetooth/l2cap_core.c:3266:24: note: 'rfc.max_pdu_size' was declared here net/bluetooth/l2cap_core.c:3298:25: warning: 'rfc.monitor_timeout' may be used uninitialized in this function [-Wmaybe-uninitialized] net/bluetooth/l2cap_core.c:3266:24: note: 'rfc.monitor_timeout' was declared here net/bluetooth/l2cap_core.c:3297:25: warning: 'rfc.retrans_timeout' may be used uninitialized in this function [-Wmaybe-uninitialized] net/bluetooth/l2cap_core.c:3266:24: note: 'rfc.retrans_timeout' was declared here net/bluetooth/l2cap_core.c:3295:2: warning: 'rfc.mode' may be used uninitialized in this function [-Wmaybe-uninitialized] net/bluetooth/l2cap_core.c:3266:24: note: 'rfc.mode' was declared here Signed-off-by:
Szymon Janc <szymon.janc@tieto.com> Signed-off-by:
-
- 11 Jun, 2012 4 commits
-
-
-
Jussi Kivilinna authored
rndis_check_bssid_list() originally tried to check if bssid->mac and match_bssid are equal using compare_ether_addr() when it should use !compare_ether_addr(). This check was added by commit b5257c95 as part of workaround for hardware issue. Commit 2e42e474 that replaced compare_ether_addr with ether_addr_equal relieved that this compare to be inverse of what it should be. Compare was added as response to hardware bug, where bssid-list does not contain BSSID and other information of currently connected AP (spec insists that device must provide this information in the list when connected). Lack bssid-data on current connection then causes WARN_ON somewhere in cfg80211. Workaround was to check if bssid-list returns current bssid and if it does not, manually construct bssid information in other ways. And this workaround worked, with inverse check. Which must mean that when hardware is experiencing the problem, it's actually returning empty bssid-list and this check didn't make any difference for workaround. However inverse check causes workaround be activated when bssid-list returns only entry, currently connected BSSID. That does not cause problems in itself, just slightly more inaccurate information in scan-list. Cc: Joe Perches <joe@perches.com> Cc: David S. Miller <davem@davemloft.net> Signed-off-by:
Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by:
-
Mohammed Shafi Shajakhan authored
'cfg80211: fix interface combinations' ensures that if an interface type is not advertised by the driver in any of the interface combinations (via ieee80211_iface_combination) then it shall be treated as a single incompatible interface. if there are more than one interfaces present and changing them to incompatible interface type is not possible. These checks will be properly handled by cfg80211_change_iface -> cfg80211_can_change_interface. this patch is dependent on 'cfg80211: fix interface combinations' Signed-off-by:
-
Mohammed Shafi Shajakhan authored
this patch is dependent on the patch "cfg80211: fix interface combinations" In ath9k currently we have ADHOC interface as a single incompatible interface. when drv_add_interface is called during resume we got to consider number of vifs already present in addition to checking the drivers 'opmode' information about ADHOC. we incorrectly assume an ADHOC interface is already present. Then we may miss some driver specific data for the ADHOC interface after resume. The above mentioned checks can be removed from the driver, as the patch 'cfg80211: fix interface combinations' ensures that if an interface type is not advertised by the driver in any of the interface combinations(via ieee80211_iface_combination) then it shall be treated as a single incompatible interface. Fixes the following warning on suspend/resume with ibss interface. ath: phy0: Cannot create ADHOC interface when other interfaces already exist. WARNING: at net/mac80211/driver-ops.h:12 ieee80211_reconfig+0x1882/0x1ca0 [mac80211]() Hardware name: 2842RK1 wlan2: Failed check-sdata-in-driver check, flags: 0x0 Call Trace: [<c01361b2>] warn_slowpath_common+0x72/0xa0 [<f8aaa7c2>] ? ieee80211_reconfig+0x1882/0x1ca0 [mac80211] [<f8aaa7c2>] ? ieee80211_reconfig+0x1882/0x1ca0 [mac80211] [<c0136283>] warn_slowpath_fmt+0x33/0x40 [<f8aaa7c2>] ieee80211_reconfig+0x1882/0x1ca0 [mac80211] [<c06c1d1a>] ? mutex_lock_nested+0x23a/0x2f0 [<f8a95097>] ieee80211_resume+0x27/0x70 [mac80211] [<fd177edf>] wiphy_resume+0x8f/0xa0 [cfg80211] Cc: stable@vger.kernel.org Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by:
-
- 09 Jun, 2012 4 commits
-
-
Marek Vasut authored
Acer used this chip connected via USB: Bus 005 Device 005: ID 0cf3:3005 Atheros Communications, Inc. AR3011 Bluetooth Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 224 Wireless bDeviceSubClass 1 Radio Frequency bDeviceProtocol 1 Bluetooth bMaxPacketSize0 64 idVendor 0x0cf3 Atheros Communications, Inc. idProduct 0x3005 AR3011 Bluetooth bcdDevice 0.01 iManufacturer 0 iProduct 0 iSerial 0 bNumConfigurations 1 Signed-off-by:
Marek Vasut <marex@denx.de> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: Johan Hedberg <johan.hedberg@gmail.com> Cc: Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Michal Kazior authored
Don't validate interface combinations on a stopped interface. Otherwise we might end up being able to create a new interface with a certain type, but won't be able to change an existing interface into that type. This also skips some other functions when interface is stopped and changing interface type. Signed-off-by:
Michal Kazior <michal.kazior@tieto.com> Signed-off-by:
-
Johannes Berg authored
Add a few kernel-doc descriptions that were missed during development. Reported-by:
-
Johan Hedberg authored
With LE/SMP the completion of a security level elavation from medium to high is indicated by a HCI Encryption Key Refresh Complete event. The necessary behavior upon receiving this event is a mix of what's done for auth_complete and encryption_change, which is also where most of the event handling code has been copied from. Signed-off-by:
-
- 08 Jun, 2012 1 commit
-
-
Stanislaw Gruszka authored
commit 24398e39 Author: Johannes Berg <johannes.berg@intel.com> Date: Wed Mar 28 10:58:36 2012 +0200 mac80211: set HT channel before association removed IEEE80211_CONF_CHANGE_CHANNEL argument from ieee80211_hw_config, which is required by iwl4965 driver, otherwise that driver does not configure channel properly and is not able to associate. Signed-off-by:
-
