- 16 Aug, 2010 39 commits
-
-
Andrea Gelmini authored
"userpace" -> "userspace" Signed-off-by: Andrea Gelmini <andrea.gelmini@gelma.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
When an AP sends a deauth frame, or we send one to an AP, that only means we lost our connection if we were actually connected to that AP. Check this to avoid sending spurious "disconnected" events and breaking "iw ... link" reporting. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
This patch introduces a new timer, which will release queued-up MPDUs from the reorder buffer, whenever they've waited for more than HT_RX_REORDER_BUF_TIMEOUT (which is at around 100 ms). The advantage of having a dedicated timer, instead of relying on a constant stream of freshly arriving aMPDUs to release the old ones, is particularly observable when even a small fraction of MPDUs are forever lost at low network speeds. Previously under these circumstances frames would become stuck in the reorder buffer and the network stack of both HT peers throttled back, instead of revving up and gunning the pipes. Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
This patch removes a few stale parameters and variables which survived the last, large rx-path reorganization: "mac80211: correctly place aMPDU RX reorder code" Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
This patch takes the reorder logic from the RX path and moves it into separate routines to make the expired frame release accessible. Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
When the noise floor limits are being bypassed because of strong interference, sensitivity is also reduced. In order to recover from this as quickly as possible, trigger a long periodic calibration every second instead of every 30 seconds, until the NF median is within limits again. This is especially important if the interference lasts for a while, since it takes multiple clean NF calibrations to bring the median back to normal. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
When beacons get stuck in AP mode, the most likely cause is interference. Such interference can often go on for a while, and too many consecutive beacon misses can lead to connected clients getting dropped. Since connected clients might not be subjected to the same interference if that happens to be very local, the AP should try to deal with it as good as it can. One way to do this is to trigger an NF calibration with automatic baseband update right after the beacon miss. In my tests with very strong interference, this allowed the AP to continue transmitting beacons after only 2-3 misses, which allows a normal client to stay connected. With some of the newer - really sensitive - chips, the maximum noise floor limit is very low, which can be problematic during very strong interference. To avoid an endless loop of stuck beacons -> nfcal -> periodic calibration -> stuck beacons, the beacon miss event also sets a flag, which allows the calibration code to bypass the chip specific maximum NF value. This flag is automatically cleared, as soon as the first NF median goes back below the limits for all chains. In my tests, this allowed an ath9k AP to survive very strong interference (measured NF: -68, or sometimes even higher) without losing connectivity to its clients. Even under these conditions, I was able to transmit several mbits/s through the interface. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
Stuck beacons are a useful indicator for debugging various PHY issues such as calibration. Putting them on the same debug level as the other beacon stuff makes it hard to spot them in huge amounts of spam. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ben Hutchings authored
ieee80211_add_key() currently returns -ENOMEM in case of any error, including a missing crypto algorithm. Change ieee80211_key_alloc() and ieee80211_aes_{key_setup_encrypt,cmac_key_setup}() to encode errors with ERR_PTR() rather than returning NULL, and change ieee80211_add_key() accordingly. Compile-tested only. Reported-by: Marcin Owsiany <porridge@debian.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Only the IBSS manager, ie. the station that sent the IBSS beacon last, should be replying to probe responses. This requires implementing the mac80211 tx_last_beacon callback, which we can do thanks to the ucode beacon notification. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Wey-Yi Guy authored
iwl_set_hw_params() only used by _agn, make it static Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Wey-Yi Guy authored
Log the information after reading the PCI_REVISION_ID from pci config space, Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Wey-Yi Guy authored
iwl_hw_detect() only used by _agn, make it static Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Thomas Klute authored
Split some long lines to make checkpatch.pl happy. ;-) Signed-off-by: Thomas Klute <thomas2.klute@uni-dortmund.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Thomas Klute authored
Signed-off-by: Thomas Klute <thomas2.klute@uni-dortmund.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Having both scan and work mutexes is not just a bit too fine grained, it also creates issues when there's code that needs both since they then need to be acquired in the right order, which can be hard to do. Therefore, use just a single mutex for both. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Stanislaw Gruszka authored
We do not need export iwl_bg.*scan.*() functions just for initialize workqueue in other module. Making that functions static helps with iwl-scan.c code review a bit. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Frames that failed PLCP error checks are most likely microwave transmissions (well, maybe not ...) and don't have a proper rate detected, so ignore it. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Dan Williams authored
Bring back the comment about FW v5 status codes from the pre-cfg80211 driver, and let through status codes that aren't remapped by the firmware. Signed-off-by: Dan Williams <dcbw@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Dan Williams authored
Make it a bit easier to debug scan results in the future. Signed-off-by: Dan Williams <dcbw@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
This helps us debug channel changes better. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
When running in client mode and associating to an AP, the channel change is usually performed with the offchannel flag still set. However after the assoc is complete, the following channel change event is suppressed because the run time channel is already set to the operating channel. Fix this by sending channel change notifications to the driver even if only the offchannel flag changes. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
This function was exiting early if the existing diversity settings were unchanged. Unfortunately, in some cases the antenna configuration is not initialized at all. https://bugzilla.kernel.org/show_bug.cgi?id=14751Signed-off-by: John W. Linville <linville@tuxdriver.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Cc: Gertjan van Wingerde <gwingerde@gmail.com>
-
John W. Linville authored
...and unregistration to core shutdown. Previously, the driver remained registered even when the hardware was shutdown. That causes the driver to return -ENODEV if the b43 device is IFF_DOWN. This change causes the driver to disappear in that case, allowing /dev/hwrng to still function if another hwrng device is available. Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
drivers/net/wireless/iwmc3200wifi/rx.c: In function 'iwm_ntf_wifi_if_wrapper': drivers/net/wireless/iwmc3200wifi/rx.c:1198: warning: comparison is always true due to limited range of data type This is, of course, because the value of WIFI_IF_NTFY_MAX is 0xff and hdr->oid is a u8. This is obviously an attempt to verify the range on an input value, but since it has no effect it can simply be removed. Signed-off-by: John W. Linville <linville@tuxdriver.com> Acked-by: Samuel Ortiz <samuel.ortiz@intel.com>
-
John W. Linville authored
drivers/net/wireless/ipw2x00/ipw2100.c: In function 'ipw2100_tx_send_commands': drivers/net/wireless/ipw2x00/ipw2100.c:3063: warning: cast to pointer from integer of different size This changes the cast and the conversion to match other usage of the same value in calls to IPW_DEBUG_TX. Reported-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
Some iwlwifi devices inexplicably disconnect themselves from the PCI-E bus causing the predictable failures. This seems to disappear if ASPM is disabled. Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
This provides a little more flexibility for human users, and it allows us to use isalpha rather than the custom is_alpha_upper. Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
This patch implement basic infrastructure to support use of NAPI by mac80211-based hardware drivers. Because mac80211 devices can support multiple netdevs, a dummy netdev is used for interfacing with the NAPI code in the core of the network stack. That structure is hidden from the hardware drivers, but the actual napi_struct is exposed in the ieee80211_hw structure so that the poll routines in drivers can retrieve that structure. Hardware drivers can also specify their own weight value for NAPI polling. Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
This makes the information available through ethtool... Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
This makes the information available through ethtool... Signed-off-by: John W. Linville <linville@tuxdriver.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
-
John W. Linville authored
This makes the information available through ethtool... Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
This makes the information available through ethtool... Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
John W. Linville authored
This makes the information available through ethtool... Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
- 13 Aug, 2010 1 commit
-
-
Maxim Levitsky authored
Atheros PCIe wireless cards handled by ath5k do require L0s disabled. For distributions shipping with CONFIG_PCIEASPM (this will be enabled by default in the future in 2.6.36) this will also mean both L1 and L0s will be disabled when a pre 1.1 PCIe device is detected. We do know L1 works correctly even for all ath5k pre 1.1 PCIe devices though but cannot currently undue the effect of a blacklist, for details you can read pcie_aspm_sanity_check() and see how it adjusts the device link capability. It may be possible in the future to implement some PCI API to allow drivers to override blacklists for pre 1.1 PCIe but for now it is best to accept that both L0s and L1 will be disabled completely for distributions shipping with CONFIG_PCIEASPM rather than having this issue present. Motivation for adding this new API will be to help with power consumption for some of these devices. Example of issues you'd see: - On the Acer Aspire One (AOA150, Atheros Communications Inc. AR5001 Wireless Network Adapter [168c:001c] (rev 01)) doesn't work well with ASPM enabled, the card will eventually stall on heavy traffic with often 'unsupported jumbo' warnings appearing. Disabling ASPM L0s in ath5k fixes these problems. - On the same card you would see a storm of RXORN interrupts even though medium is idle. Credit for root causing and fixing the bug goes to Jussi Kivilinna. Cc: David Quan <David.Quan@atheros.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Tim Gardner <tim.gardner@canonical.com> Cc: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Cc: stable@kernel.org Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-