- 15 Jun, 2010 12 commits
-
-
Helmut Schaa authored
In some corner cases the reported tx rates/retries didn't match the really used ones. The hardware lowers the tx rate on each consecutive retry by 1 (but won't fall back from MCS to legacy rates) _until_ it reaches the lowest one. In case the frame wasn't sent succesful the number of retries is 7 and if a rate index <7 was used the previous code reported negative rate indexes which were then ignored by the rate control algorithm and mac80211. Instead, report the remaining number of retries to have happened with the lowest rate (index 0). This should give the rate control algorithm slightly more accurate information about the used tx rates/retries. Signed-off-by:
Helmut Schaa <helmut.schaa@googlemail.com> Acked-by:
Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by:
Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Helmut Schaa authored
Set up max_rates and max_rate_tries with suitable values even if we do not support the whole functionality. As rt2800 has a global fallback table we cannot specify more then one tx rate per frame but since the hw will try several different rates (based on the fallback table) we should still initialize max_rates to the maximum number of rates we are going to try. Otherwise mac80211 will truncate our reported tx rates and the rc algortihm will end up with incorrect data choosing unsuitable rates for tx. This improves throughput on rt2800 devices considerable. Signed-off-by:
-
Helmut Schaa authored
Fix typo in rt2800_config_txpower. Signed-off-by:
-
Helmut Schaa authored
Currently rt2800pci will read TX_STA_FIFO until the previously read value matches the current value. However, it is obvious that TX_STA_FIFO only contains values that can easily be the same for multiple consecutive frames (especially when communicating with only one other STA). Hence, we often ended up with reading only the first entry and ignoring the rest. One result was that when the TX_STA_FIFO contained multiple entires, only the first one was read and properly handled while the others remained in the tx queue. Thus, drop this check but introduce a maximum number of reads. All legacy drivers use the size of the tx ring as limit but state that the TX_STA_FIFO has only 16 entries. So, let's just stick with the tx ring size for now. Signed-off-by:
-
Helmut Schaa authored
Add a comment about the meaning of BBP1_TX_POWER stating all possible values. Signed-off-by:
-
Helmut Schaa authored
IEEE80211_TX_CTL_MORE_FRAMES indicates that more frames are queued for tx but has nothing to do with fragmentation. Hence, don't set ENTRY_TXD_MORE_FRAG but only ENTRY_TXD_BURST to not kick the tx queues immediately. Signed-off-by:
-
Helmut Schaa authored
TXDONE_FALLBACK expresses that fallback rates were used for retries. Hence, it only makes sense to set the flag if retries > 0. Signed-off-by:
-
Helmut Schaa authored
TXDONE_FALLBACK doesn't express if the frame was sent successful or not. It only tells us that the hw used fallback rates for retries. Hence, don't use TXDONE_FALLBACK as success indicator. Before this patch we reported success to the rate control algorithm which was wrong in a number of cases and might have lead to improper tx rate selections. Signed-off-by:
-
Helmut Schaa authored
Update the documentation of the available txdone flags to better express how they should be used. Signed-off-by:
-
Jouni Malinen authored
When management frame protection (IEEE 802.11w) is used, we must use a separate counter for tracking received CCMP packet number for the management frames. The previously used NUM_RX_DATA_QUEUESth queue was shared with data frames when QoS was not used and that can cause problems in detecting replays incorrectly for robust management frames. Add a new counter just for robust management frames to avoid this issue. Signed-off-by:
Jouni Malinen <jouni.malinen@atheros.com> Signed-off-by:
-
Jouni Malinen authored
When management frame protection (IEEE 802.11w) is used, Deauthentication frame needs to be protected when the pairwise key is configured. mac80211 was removing the station entry (and its keys) before actually sending out the Deauthentication frame. Fix this by reordering the code to send the frame before the station entry gets removed. This matches an earlier change that handled the Disassociation frame processing, but missed Deauthentication frames. Signed-off-by:
-
Juuso Oikarinen authored
The ps-qos latency handling is broken. It uses predetermined latency values to select specific dynamic PS timeouts. With common AP configurations, these values overlap with beacon interval and are therefore essentially useless (for network latencies less than the beacon interval, PSM is disabled.) This patch remedies the problem by replacing the predetermined network latency values with one high value (1900ms) which is used to go trigger full psm. For backwards compatibility, the value 2000ms is still mapped to a dynamic ps timeout of 100ms. Currently also the mac80211 internal value for storing user space configured dynamic PSM values is incorrectly in the driver visible ieee80211_conf struct. Move it to the ieee80211_local struct. Signed-off-by:
Juuso Oikarinen <juuso.oikarinen@nokia.com> Signed-off-by:
-
- 14 Jun, 2010 28 commits
-
-
Juuso Oikarinen authored
There is a circular locking dependency when configuring the hardware ARP filters on association, occurring when flushing the mac80211 workqueue. This is what happens: [ 92.026800] ======================================================= [ 92.030507] [ INFO: possible circular locking dependency detected ] [ 92.030507] 2.6.34-04781-g2b2c009e #85 [ 92.030507] ------------------------------------------------------- [ 92.030507] modprobe/5225 is trying to acquire lock: [ 92.030507] ((wiphy_name(local->hw.wiphy))){+.+.+.}, at: [<ffffffff8105b5c0>] flush_workq ueue+0x0/0xb0 [ 92.030507] [ 92.030507] but task is already holding lock: [ 92.030507] (rtnl_mutex){+.+.+.}, at: [<ffffffff812b9ce2>] rtnl_lock+0x12/0x20 [ 92.030507] [ 92.030507] which lock already depends on the new lock. [ 92.030507] [ 92.030507] [ 92.030507] the existing dependency chain (in reverse order) is: [ 92.030507] [ 92.030507] -> #2 (rtnl_mutex){+.+.+.}: [ 92.030507] [<ffffffff810761fb>] lock_acquire+0xdb/0x110 [ 92.030507] [<ffffffff81341754>] mutex_lock_nested+0x44/0x300 [ 92.030507] [<ffffffff812b9ce2>] rtnl_lock+0x12/0x20 [ 92.030507] [<ffffffffa022d47c>] ieee80211_assoc_done+0x6c/0xe0 [mac80211] [ 92.030507] [<ffffffffa022f2ad>] ieee80211_work_work+0x31d/0x1280 [mac80211] [ 92.030507] -> #1 ((&local->work_work)){+.+.+.}: [ 92.030507] [<ffffffff810761fb>] lock_acquire+0xdb/0x110 [ 92.030507] [<ffffffff8105a51a>] worker_thread+0x22a/0x370 [ 92.030507] [<ffffffff8105ecc6>] kthread+0x96/0xb0 [ 92.030507] [<ffffffff81003a94>] kernel_thread_helper+0x4/0x10 [ 92.030507] [ 92.030507] -> #0 ((wiphy_name(local->hw.wiphy))){+.+.+.}: [ 92.030507] [<ffffffff81075fdc>] __lock_acquire+0x1c0c/0x1d50 [ 92.030507] [<ffffffff810761fb>] lock_acquire+0xdb/0x110 [ 92.030507] [<ffffffff8105b60e>] flush_workqueue+0x4e/0xb0 [ 92.030507] [<ffffffffa023ff7b>] ieee80211_stop_device+0x2b/0xb0 [mac80211] [ 92.030507] [<ffffffffa0231635>] ieee80211_stop+0x3e5/0x680 [mac80211] The locking in this case is quite complex. Fix the problem by rewriting the way the hardware ARP filter list is handled - i.e. make a copy of the address list to the bss_conf struct, and provide that list to the hardware driver when needed. The current patch will enable filtering also in promiscuous mode. This may need to be changed in the future. Reported-by:
Reinette Chatre <reinette.chatre@intel.com> Signed-off-by:
-
Teemu Paasikivi authored
Remove BSS from cfg80211 BSS list if we are only member in IBSS when leaving it. Signed-off-by:
Teemu Paasikivi <ext-teemu.3.paasikivi@nokia.com> Acked-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
Teemu Paasikivi authored
Add changed basic rates flag to bss_changed while joinig ibss network. This patch is split from the patch containing support for setting basic rates when creating ibss network. Original patch was posted by Johannes Berg on the linux-wireless posting list. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Teemu Paasikivi authored
This patch adds support to nl80211 and mac80211 to set basic rates when joining/creating ibss network. Original patch was posted by Johannes Berg on the linux-wireless posting list. Signed-off-by:
-
Felix Fietkau authored
This capability check is no longer used, so it can be removed along with the now-obsolete ath9k_hw_getcapability function. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Felix Fietkau authored
mac80211 already masks the HT sta capabilities based on hardware support Signed-off-by:
-
Felix Fietkau authored
The driver always sets this to enabled, but this can be simplified with a small change to ah->sta_id1_defaults instead. This change also removes the now-obsolete ath9k_hw_setcapability function. Signed-off-by:
-
Felix Fietkau authored
This is only used as a workaround for an issue in one specific hw revision. Signed-off-by:
-
Felix Fietkau authored
TKIP MIC support is always enabled anyway. Signed-off-by:
-
Felix Fietkau authored
replace calls that read this capability with accesses to ath9k_hw's regulatory data. Signed-off-by:
-
Felix Fietkau authored
All of the ciphers that are tested for are always supported Signed-off-by:
-
Luis R. Rodriguez authored
All AR9003 features are now complete so enable AR9003 support. Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
-
Felix Fietkau authored
Signed-off-by:
-
Felix Fietkau authored
Signed-off-by:
-
Felix Fietkau authored
Signed-off-by:
-
Felix Fietkau authored
Signed-off-by:
-
Felix Fietkau authored
ath9k_hw_setmac() only copies the mac address it is called with into common->macaddr, yet in all call sites, the supplied mac address pointer is already common->macaddr. Signed-off-by:
-
Felix Fietkau authored
Debugfs requires a u32 for bool knobs though so we turn the ath9k_hw knob into a u32 as well. Signed-off-by:
-
Felix Fietkau authored
ath9k tries to prevent WMM queue tx buffer starvation caused by traffic on different queues by limiting the number of pending frames in a tx queue (tracked in the ath_buf structure). This had a leak issue, because the a skb can be reassigned to a different ath_buf in the tx path, causing the pending frame counter to become inaccurate. To fix this, track the number of frames in an array in the softc, using the mac80211 queue mapping as index. Signed-off-by:
-
Felix Fietkau authored
AR5416 and all newer chipsets use a 32 bit rx timestamp, so there is no need to keep the 15 bit timestamp extending logic around. This patch removes ath9k_hw_extend_tsf (replaced by a call to ath9k_hw_gettsf64), and reduces the frequency of TSF reads, which can improve performance in some cases. This change also has the side effect of making rx timestamps more accurate. Signed-off-by:
-
Felix Fietkau authored
Signed-off-by:
-
Felix Fietkau authored
Signed-off-by:
-
Felix Fietkau authored
Signed-off-by:
-
Felix Fietkau authored
Signed-off-by:
-
Felix Fietkau authored
ath_get_mac80211_qnum() expects the queue 'subtype' (internal ID for the WMM AC) as argument when looking up the mac80211 queue, however ath_wake_mac80211_queue provides txq->axq_qnum instead, which contains the hardware queue number. Fix this by keeping track of the WMM class ID in the txq data structure. Signed-off-by:
-
Luis R. Rodriguez authored
This updates the initvals for AR9003 to adjust the 5 GHz tx gain tables for femless and high power PA. References: Osprey 2.0 header file ver 72 Osprey 2.2 header file ver 20 Checksums: $ ./initvals -f ar9003-2p0 0x00000000c2bfa7d5 ar9300_2p0_radio_postamble 0x00000000ada2b114 ar9300Modes_lowest_ob_db_tx_gain_table_2p0 0x00000000e0bc2c84 ar9300Modes_fast_clock_2p0 0x00000000056eaf74 ar9300_2p0_radio_core 0x0000000000000000 ar9300Common_rx_gain_table_merlin_2p0 0x0000000078658fb5 ar9300_2p0_mac_postamble 0x0000000023235333 ar9300_2p0_soc_postamble 0x0000000054d41904 ar9200_merlin_2p0_radio_core 0x00000000748572cf ar9300_2p0_baseband_postamble 0x000000009aa5a0a4 ar9300_2p0_baseband_core 0x000000003dffa526 ar9300Modes_high_power_tx_gain_table_2p0 0x000000001cfda724 ar9300Modes_high_ob_db_tx_gain_table_2p0 0x0000000011302700 ar9300Common_rx_gain_table_2p0 0x00000000e3eab114 ar9300Modes_low_ob_db_tx_gain_table_2p0 0x00000000c9d66d40 ar9300_2p0_mac_core 0x000000001e1d0800 ar9300Common_wo_xlna_rx_gain_table_2p0 0x00000000a0c54980 ar9300_2p0_soc_preamble 0x00000000292e2544 ar9300PciePhy_pll_on_clkreq_disable_L1_2p0 0x000000002d3e2544 ar9300PciePhy_clkreq_enable_L1_2p0 0x00000000293e2544 ar9300PciePhy_clkreq_disable_L1_2p0 $ ./initvals -f ar9003-2p2 0x00000000c2bfa7d5 ar9300_2p2_radio_postamble 0x00000000ada2b114 ar9300Modes_lowest_ob_db_tx_gain_table_2p2 0x00000000e0bc2c84 ar9300Modes_fast_clock_2p2 0x00000000056eaf74 ar9300_2p2_radio_core 0x0000000000000000 ar9300Common_rx_gain_table_merlin_2p2 0x0000000078658fb5 ar9300_2p2_mac_postamble 0x0000000023235333 ar9300_2p2_soc_postamble 0x0000000054d41904 ar9200_merlin_2p2_radio_core 0x000000008475a084 ar9300_2p2_baseband_postamble 0x000000009aaafd90 ar9300_2p2_baseband_core 0x000000003dffa526 ar9300Modes_high_power_tx_gain_table_2p2 0x000000001cfda724 ar9300Modes_high_ob_db_tx_gain_table_2p2 0x0000000011302700 ar9300Common_rx_gain_table_2p2 0x00000000a9a2b114 ar9300Modes_low_ob_db_tx_gain_table_2p2 0x00000000a9d66d40 ar9300_2p2_mac_core 0x000000001e1d0800 ar9300Common_wo_xlna_rx_gain_table_2p2 0x00000000a0c531c8 ar9300_2p2_soc_preamble 0x00000000292e2544 ar9300PciePhy_pll_on_clkreq_disable_L1_2p2 0x000000002d3e2544 ar9300PciePhy_clkreq_enable_L1_2p2 0x00000000293e2544 ar9300PciePhy_clkreq_disable_L1_2p2 Signed-off-by:
-
Luis R. Rodriguez authored
All AR9003 devices are PCI-E only, the extra delay here is not required and only reduces the delay for loading the initial register values by at least 14ms. Signed-off-by:
-
Luis R. Rodriguez authored
AR9003 has been tested with the new ANI implementation and so ANI can now be enabled for that family. Signed-off-by:
-
