- 04 Aug, 2009 40 commits
-
-
Wey-Yi Guy authored
For 6x00 2x2 NIC, two types of Power Amplifier are available. In order for uCode to apply correct tx power, driver needs to program the CSR_GP_DRIVER_REG register and let uCode know the type of PA. If driver do not program CSR_GP_DRIVER_REG register (default to 0), then it is uCode's decision for tx power 2x2 Hybrid card: use both internal and external PA 2x2 IPA(Internal Power Amplifier) card: internal PA only Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
Reinette Chatre <reinette.chatre@intel.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Daniel C Halperin authored
Resolve an issue in which out-dated fields in iwl_cmd_meta could be used for later hardware commands. Signed-off-by:
Daniel C Halperin <daniel.c.halperin@intel.com> Signed-off-by:
-
gregor kowski authored
The tkip hw support uncovered a bug in b43_write_probe_resp_template : it is writing at the wrong shm offset, it is in the B43_SHM_SH_TKIPTSCTTAK zone. This patch comments these writes. Signed-off-by:
Gregor Kowski <gregor.kowski@gmail.com> Signed-off-by:
Michael Buesch <mb@bu3sch.de> Signed-off-by:
-
Michael Buesch authored
This fixes unaligned 32bit SHM-shared read/write access. The low and high 16 bits were swapped. It also adds a testcase for this to the chipaccess validation. (Thanks to Albert Herranz for tracking down this bug.) Signed-off-by:
-
Andrey Yurovsky authored
The SPI driver writes to the bus mode register and performs a sanity check by reading back what we wrote, however only the lower four bits of that register are defined. In some cases, the device side seems to set the higher bits, causing us to fail the sanity check unnecessarily. Check only the lower four bits instead. Thanks to John Goyette from Schick Technologies for pointing out the problem. Signed-off-by:
Andrey Yurovsky <andrey@cozybit.com> Signed-off-by:
-
Maxim Levitsky authored
Do a probe request every 30 seconds, and wait for probe response, half a second This should lower the traffic that card sends, thus save power Wainting longer for response makes probe more robust against 'slow' access points Signed-off-by:
Maxim Levitsky <maximlevitsky@gmail.com> Acked-by:
Johannes Berg <johannes@sipsolutions.net> Tested-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Maxim Levitsky authored
Retry 5 times (chosen arbitary ), before assuming that station is out of range. Fixes frequent disassociations while connected to weak, and sometimes even strong access points. Signed-off-by:
-
Johannes Berg authored
The default of 500ms is pretty high, and leads to the device being awake at least 50% of the time under such light traffic conditions as a simple 1 second interval ping. Reduce to just 100ms -- it should have a similar effect while providing a better sleep time. Signed-off-by:
Kalle Valo <kalle.valo@iki.fi> Signed-off-by:
-
Luis R. Rodriguez authored
This is a private flag, internal to cfg80211. cfg80211 will set orig_* stuff internally upon wiphy registration, drivers do not need to muck with it. Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Acked-by:
-
Luis R. Rodriguez authored
Since the bss is always set now once we are connected, if the bss has its own information element we refer to it and pass that instead of relying on mac80211's parsing. Now all cfg80211 drivers get country IE support, automatically and we reduce the call overhead that we had on mac80211 which called this upon every beacon and instead now call this only upon a successfull connection by a STA on cfg80211. Acked-by:
-
Luis R. Rodriguez authored
We change regulatory code to be protected by its own regulatory mutex and alleviate cfg80211_mutex to only be used to protect cfg80211_rdev_list, the registered device list. By doing this we will be able to work on regulatory core components without having to have hog up the cfg80211_mutex. An example here is we no longer need to use the cfg80211_mutex during driver specific wiphy_apply_custom_regulatory(). We also no longer need it for the the country IE regulatory hint; by doing so we end up curing this new lockdep warning: ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.31-rc4-wl #12 ------------------------------------------------------- phy1/1709 is trying to acquire lock: (cfg80211_mutex){+.+.+.}, at: [<ffffffffa00af852>] regulatory_hint_11d+0x32/0x3f0 [cfg80211] but task is already holding lock: (&ifmgd->mtx){+.+.+.}, at: [<ffffffffa0144228>] ieee80211_sta_work+0x108/0x10f0 [mac80211] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (&ifmgd->mtx){+.+.+.}: [<ffffffff810857b6>] __lock_acquire+0xd76/0x12b0 [<ffffffff81085dd3>] lock_acquire+0xe3/0x120 [<ffffffff814eeae4>] mutex_lock_nested+0x44/0x350 [<ffffffffa0141bb8>] ieee80211_mgd_auth+0x108/0x1f0 [mac80211] [<ffffffffa0148563>] ieee80211_auth+0x13/0x20 [mac80211] [<ffffffffa00bc3a1>] __cfg80211_mlme_auth+0x1b1/0x2a0 [cfg80211] [<ffffffffa00bc516>] cfg80211_mlme_auth+0x86/0xc0 [cfg80211] [<ffffffffa00b368d>] nl80211_authenticate+0x21d/0x230 [cfg80211] [<ffffffff81416ba6>] genl_rcv_msg+0x1b6/0x1f0 [<ffffffff81415c39>] netlink_rcv_skb+0x89/0xb0 [<ffffffff814169d9>] genl_rcv+0x29/0x40 [<ffffffff8141591d>] netlink_unicast+0x29d/0x2b0 [<ffffffff81416514>] netlink_sendmsg+0x214/0x300 [<ffffffff813e4407>] sock_sendmsg+0x107/0x130 [<ffffffff813e45b9>] sys_sendmsg+0x189/0x320 [<ffffffff81011f82>] system_call_fastpath+0x16/0x1b [<ffffffffffffffff>] 0xffffffffffffffff -> #2 (&wdev->mtx){+.+.+.}: [<ffffffff810857b6>] __lock_acquire+0xd76/0x12b0 [<ffffffff81085dd3>] lock_acquire+0xe3/0x120 [<ffffffff814eeae4>] mutex_lock_nested+0x44/0x350 [<ffffffffa00ab304>] cfg80211_netdev_notifier_call+0x1a4/0x390 [cfg80211] [<ffffffff814f3dff>] notifier_call_chain+0x3f/0x80 [<ffffffff81075a91>] raw_notifier_call_chain+0x11/0x20 [<ffffffff813f665a>] dev_open+0x10a/0x120 [<ffffffff813f59bd>] dev_change_flags+0x9d/0x1e0 [<ffffffff8144eb6e>] devinet_ioctl+0x6fe/0x760 [<ffffffff81450204>] inet_ioctl+0x94/0xc0 [<ffffffff813e25fa>] sock_ioctl+0x6a/0x290 [<ffffffff8111e911>] vfs_ioctl+0x31/0xa0 [<ffffffff8111ea9a>] do_vfs_ioctl+0x8a/0x5c0 [<ffffffff8111f069>] sys_ioctl+0x99/0xa0 [<ffffffff81011f82>] system_call_fastpath+0x16/0x1b [<ffffffffffffffff>] 0xffffffffffffffff -> #1 (&rdev->mtx){+.+.+.}: [<ffffffff810857b6>] __lock_acquire+0xd76/0x12b0 [<ffffffff81085dd3>] lock_acquire+0xe3/0x120 [<ffffffff814eeae4>] mutex_lock_nested+0x44/0x350 [<ffffffffa00ac4d0>] cfg80211_get_dev_from_ifindex+0x60/0x90 [cfg80211] [<ffffffffa00b21ff>] get_rdev_dev_by_info_ifindex+0x6f/0xa0 [cfg80211] [<ffffffffa00b51eb>] nl80211_set_interface+0x3b/0x260 [cfg80211] [<ffffffff81416ba6>] genl_rcv_msg+0x1b6/0x1f0 [<ffffffff81415c39>] netlink_rcv_skb+0x89/0xb0 [<ffffffff814169d9>] genl_rcv+0x29/0x40 [<ffffffff8141591d>] netlink_unicast+0x29d/0x2b0 [<ffffffff81416514>] netlink_sendmsg+0x214/0x300 [<ffffffff813e4407>] sock_sendmsg+0x107/0x130 [<ffffffff813e45b9>] sys_sendmsg+0x189/0x320 [<ffffffff81011f82>] system_call_fastpath+0x16/0x1b [<ffffffffffffffff>] 0xffffffffffffffff other info that might help us debug this: 3 locks held by phy1/1709: #0: ((wiphy_name(local->hw.wiphy))){+.+.+.}, at: [<ffffffff8106b45d>] worker_thread+0x19d/0x340 #1: (&ifmgd->work){+.+.+.}, at: [<ffffffff8106b45d>] worker_thread+0x19d/0x340 #2: (&ifmgd->mtx){+.+.+.}, at: [<ffffffffa0144228>] ieee80211_sta_work+0x108/0x10f0 [mac80211] Reported-by: -
Luis R. Rodriguez authored
Simplify the country IE hint code by just bailing out if a previous country IE has been issued. We currently just trust the first AP we connect to on any card. The idea was to perform conflict resolution within this routine but since we can no longer iterate over the registered device list here we leave conflict resolution to be dealt with at a later time on the workqueue. This code has no functional changes other than saving us an interation over the registered device list when a second card is connected, or you unplug and connect the same one, and a country IE is received. This would have been done upon every beacon received. Signed-off-by:
-
Luis R. Rodriguez authored
This has no functional changes. Acked-by:
-
Johannes Berg authored
Some of the recent MLME rework I did broke powersave because the ps_sdata isn't assigned at the right time, and the work item wasn't removed from the list before calling ieee80211_recalc_ps(). To be more specific, this broke the case where you'd enabled PS before associating, either automatically or with iwconfig. Signed-off-by:
-
Jussi Kivilinna authored
Organize key data in private structure better and store WPA keys, so they can be restored as WEP keys. Signed-off-by:
Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by:
-
Jussi Kivilinna authored
OID_802_11_REMOVE_KEY failed with invalid length error, add missing padding to structure fix this. Signed-off-by:
-
Jussi Kivilinna authored
Add handling for 802.11 specific rndis indications. Signed-off-by:
-
Jussi Kivilinna authored
Allow rndis_wlan to see all indications. Currently rndis_host lets rndis_wlan to know about link state changes only, but there is whole set of other 802.11-specific indications that rndis_wlan should handle properly. So rename link_change() to indication() and convert rndis_wlan to use it. Signed-off-by:
-
Jussi Kivilinna authored
Add better debugging for failed OID queries. Signed-off-by:
-
Jussi Kivilinna authored
Set current packet filter to zero to block receiving data packets from device. Signed-off-by:
-
Jussi Kivilinna authored
Reset device properly with RNDIS_MSG_RESET in rndis_wlan_reset() and restore multicast list afterwards. Signed-off-by:
-
Jussi Kivilinna authored
Scanning gets stuck if device is stopped when scan is active. Fix by clearing/aborting cfg80211 scan on rndis_wlan_stop(). Signed-off-by:
-
Jussi Kivilinna authored
Driver doesn't need to poll statistics/link status when stopped. Signed-off-by:
-
Jussi Kivilinna authored
rndis_wlan devices freeze after running usbnet_stop several times. It appears that firmware freezes in state where it does not respond to any RNDIS commands and device have to be physically unplugged/replugged. This patch lets minidrivers to disable unlink_urbs on usbnet_stop through new info flag. Signed-off-by:
-
Johannes Berg authored
It's possible to get the NETDEV_UNREGISTER callback multiple times (see net/core/dev.c:netdev_wait_allrefs) and this will completely mess up our cleanup code. To avoid that, clean up only when the interface is still on the wiphy interface list from which it's removed on the first NETDEV_UNREGISTER call. Signed-off-by:
-
Johannes Berg authored
Even with the split into iwlcore/agn/3945 not all symbols that cross file boundaries are needed in other modules, a few are only used within iwlcore, for example. Signed-off-by:
-
Luis R. Rodriguez authored
The mac80211 workqueue exists to enable mac80211 and drivers to queue their own work on a single threaded workqueue. mac80211 takes care to flush the workqueue during suspend but we never really had requirements on drivers for how they should use the workqueue in consideration for suspend. We extend mac80211 to document how the mac80211 workqueue should be used, how it should not be used and finally move raw access to the workqueue to mac80211 only. Drivers and mac80211 use helpers to queue work onto the mac80211 workqueue: * ieee80211_queue_work() * ieee80211_queue_delayed_work() These helpers will now warn if mac80211 already completed its suspend cycle and someone is trying to queue work. mac80211 flushes the mac80211 workqueue prior to suspend a few times, but we haven't taken the care to ensure drivers won't add more work after suspend. To help with this we add a warning when someone tries to add work and mac80211 already completed the suspend cycle. Drivers should ensure they cancel any work or delayed work in the mac80211 stop() callback. Signed-off-by:
-
Luis R. Rodriguez authored
This driver only uses the mac80211 workqueue and mac80211 requires us to cancel all work at driver stop. Since we now have the cancels in the right places at stop() we really don't need to flush the mac80211 workqueue so remove it. Signed-off-by:
-
Bob Copeland authored
We need to process tx descriptors for all queues (currently main tx queue and cabq) which may have triggered the TX completion interrupt. Otherwise, the queues can get stuck after sending a few frames. Signed-off-by:
Bob Copeland <me@bobcopeland.com> Signed-off-by:
-
Holger Schurig authored
Signed-off-by:
Holger Schurig <hs4233@mail.mn-solutions.de> Signed-off-by:
-
Luis R. Rodriguez authored
Cc: Christian Lamparter <chunkeey@web.de> Signed-off-by:
-
Larry Finger authored
As shown in http://thread.gmane.org/gmane.linux.kernel.wireless.general/36497, mac80211 has a bug that allows a call to the TX routine after the queues have been stopped. This situation will only occur under extreme stress. Although b43 does not crash when this condition occurs, it does generate a WARN_ON and also logs a queue overrun message. This patch recognizes b43 is not at fault and logs a message only when the most verbose debugging mode is enabled. In the unlikely event that the queue is not stopped when the DMA queue becomes full, then a warning is issued. During testing of this patch with one output stream running repeated tcpperf writes and a second running a flood ping, this routine was entered with the DMA ring stopped about once per hour. The condition where the DMA queue is full but the ring has not been stopped has never been seen by me. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Bob Copeland authored
Previously, we would store the operating mode at interface up time, but only update the PCU registers when the next reset happened. The result is that if beacon configuration (ops->bss_info_changed) happens before ops->config, we will program the wrong things into the timer registers. Consequently, beacons won't work in AP mode until after a reset (channel change, scan etc.). This is fragile anyway so just program the opmode as soon as mac80211 gives it to us. Signed-off-by:
-
Johannes Berg authored
sparse complains about a shadowed variable, which we can just rename, and lots of stuff if the API tracer is enabled, so kick out the tracer code in a sparse run -- the macros just confuse it. Signed-off-by:
-
Vasanthakumar Thiagarajan authored
Signed-off-by:
Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by:
-
Vasanthakumar Thiagarajan authored
Monotonicity of packet error rate should be kept when moving from one phy to another (legacy to ht, ht single stream to dual, etc). Current code skips updating per for other phys. Signed-off-by:
-
Vasanthakumar Thiagarajan authored
Now the lowest rate in 11na ht40 mode is 13.5Mbps this shortens the range when compared to 11na ht20 mode where the lowest rate is 6.5Mbps. To improve the range, make 6.5Mbps as the lowest rate in 11na ht40 mode, this improves the range by approximately 2dB. 11ng ht40 does not have this issue as it also has basic rates (1, 2, 5.5 and 11). Signed-off-by:
-
Johannes Berg authored
When a userspace SME is active, we're currently not keeping track of the BSS properly for reporting the current link and for internal use. Additionally, it looks like there is a possible BSS leak in that the BSS never gets removed from auth_bsses[]. To fix it, pass the BSS struct to __cfg80211_connect_result in this case. Signed-off-by:
-
Bob Copeland authored
When downing interfaces, it's a good idea to tell the driver to stop sending beacons; that way the driver doesn't need special code in ops->remove_interface() when it should already handle the case in bss_info_changed(). This fixes a potential crash with at least ath5k since the vif pointer will be nullified while beacon interrupts are still active. Signed-off-by:
-
Ivo van Doorn authored
When only rt2400pci or rt2500pci is compiled without any of the other rt2x00 modules, then CONFIG_RT2X00_LIB_CRYPTO will not be enabled. However rt2x00mac_set_tim() implemented within #ifdef CONFIG_RT2X00_LIB_CRYPTO statements while the declaration is placed outside the definition. This results in linking errors as reporte by Ken. rt2x00_set_tim() has nothing to do with crypto, and thus should be moved outside of the #ifdef statements. Signed-off-by:
Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by:
-
