- 28 Sep, 2010 4 commits
-
-
Christian Lamparter authored
tx_ampdu_upload was not decreased when an a-MPDU frame had to be kicked out from the tx_pending queues. This broke ampdu aggregation, because the scheduler waits until tx_ampdu_upload drops to zero, before making the next aggregate. Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
This patch removes some cruft, which survived the RFC review phase. Originally, carl9170_tx_ampdu_queue erroneously dropped a lot of frames. As a result the ampdu scheduler bogged down quite frequently and the affected BA session timed out. However this bug has been fixed and the WA and its debugfs counter is no longer useful. Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
"The convention seems to be angle brackets around URLS in Kconfig." -- Finn Thain (to update web addresses in the kernel) Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
802.11n-2009 demands in 11.2.1: " When a STA enters normal (non-APSD) PS mode, any downlink Block ACK agreement without an associated schedule is suspended for the duration of this PS mode." The operative word is "suspended" and not terminated. Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- 27 Sep, 2010 6 commits
-
-
Rajkumar Manoharan authored
The following commit removed splitmic. But forgot to add ATH_CRYPT_CAP_MIC_COMBINED flag for HTC drivers which causes TKIP to fail. Author: Bruno Randolf <br1@einfach.org> Date: Wed Sep 8 16:04:54 2010 +0900 ath/ath9k: Replace common->splitmic with a flag Replace common->splitmic with ATH_CRYPT_CAP_MIC_COMBINED flag. Signed-off-by:
Rajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Ben Greear authored
The old ieee80211_find_sta_by_hw method didn't properly find VIFS when there was more than one per AP. This caused AMPDU logic in ath9k to get the wrong VIF when trying to account for transmitted SKBs. This patch changes ieee80211_find_sta_by_hw to take a localaddr argument to distinguish between VIFs with the same AP but different local addresses. The method name is changed to ieee80211_find_sta_by_ifaddr. Signed-off-by:
Ben Greear <greearb@candelatech.com> Acked-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
Since AR9287 v1.0 was never sold (and the initvals removed), its revision checks can be simplified similar to AR9280 Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
Since AR9285 v1.0 and v1.1 were never sold (and the initvals removed), its revision checks can be simplified similar to AR9280 Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
Since AR9280 v1.0 was never sold (and the initvals removed), v1.0 specific revision checks can be removed and the 'v2.0 or later' check can be simplified to a check for AR9280 or later. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Ben Greear authored
Helps with debugging virtual interfaces. Signed-off-by:
Ben Greear <greearb@candelatech.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- 24 Sep, 2010 2 commits
-
-
Rajkumar Manoharan authored
This patch ensures fair beacon distribution in IBSS mode by configuring proper CWmin based on slot time. Signed-off-by:
Rajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Vasanthakumar Thiagarajan authored
Paprd needs to be done only on active chains(not for all the chains that hw can support). The paprd training frames which are sent for inactive chains would be hanging on the hw queue without getting transmitted and would make the connection so unstable. This issue happens only with the hw which supports paprd cal(ar9003). Signed-off-by:
Vasanthakumar Thiagarajan <vasanth@atheros.com> Cc: stable@kernel.org Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- 21 Sep, 2010 24 commits
-
-
Felix Fietkau authored
ath9k can use minstrel_ht instead, so it makes sense to save some space here. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
It is not used anywhere else and can be made static Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
The tid aggregation cleanup is a bit fragile, as it discards failed subframes in some places, and retransmits them in others. This could block the cleanup of an existing aggregation session, if a retransmission for a tid is issued, yet the tid is never scheduled again because of the cleanup state. Fix this by getting rid of as many subframes as possible, as early as possible, and immediately transmitting pending subframes as regular HT frames instead of waiting for the cleanup to complete. Drop all pending subframes while keeping track of the Block ACK window during aggregate tx completion to prevent sending out stale subframes, which could confuse the receiver side. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Cc: stable@kernel.org Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
A new aggregation session start can be issued by mac80211, even when the cleanup of the previous session has not completed yet. Since the data structure for the session is not recreated, this could corrupt the block ack window and lock up the aggregation session. Fix this by delaying the new session until the old one has been cleaned up. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Cc: stable@kernel.org Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
There's no reason to keep pointers to pending tx buffers around, if they're only used to keep track of which frames are still pending. Use a bitfield instead. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
This is a obvious bug, skb_queue_walk does not work if the iterator gets removed from the queue. Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
The driver has a set of different initvals for 20 MHz vs dynamic HT2040 operation. Because we can't change some of the registers "in-flight", the driver needs to perform a warm reset. Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
Don't mark the device as completely dead just yet. If all goes to plan and carl9170_reboot succeeds then we can skip the expensive userspace-driven reinitialization anyway. And if it doesn't and carl9170_reboot fails, then carl9170_usb_cancel_urbs will do the necessary steps. Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
This patch prevents the tasklet code from interfering while the firmware is down for an unscheduled maintenance. Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
According to Atheros, chain 1 is not connected. Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
Ever since carl9170 gained support to read the noisefloor, the reported noisefloor level was pretty poor. Initially I assumed that something was wrong in the PHY setup and it would be impossible to fix without any guidances. But this was not the case. In fact the nf readings were correct and the thing that was broken was the "simple" sign extension code! Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
The eeprom provides a mask for all present rx chains. Why not use it instead of the generic initval default? Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
Add the mac80211 callback function to configure the tx queue properties like cw_min, cw_max and aifs. Signed-off-by:
Bruno Randolf <br1@einfach.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
Get rid of overly complicated cw_min/max and AIFS configuration: * Validate values in ath5k_hw_set_tx_queueprops(), so we can use them directly without further checks or computation in ath5k_hw_reset_tx_queue(). * Simplifiy by using AR5K_TUNE_AIFS|CWMIN|CWMAX variables directly since we don't support XR or B channels. That way we can also remove AR5K_TXQ_USEDEFAULT and the confusing logic around it. * Update data types: AIFS is u8, CW's are u16. * Remove now unneeded variables in ath5k_hw. Signed-off-by:
Bruno Randolf <br1@einfach.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
If we return a TX descriptor to the pool of available descriptors, while a queues TXDP still points to it we could potentially run into all sorts of troube. It has been suggested that there is hardware which can set the descriptors done bit before it reads ds_link and moves on to the next descriptor. While the documentation says this is not true for newer chipsets (the descriptor contents are copied to some internal memory), we don't know about older hardware. To be safe, we always keep the last descriptor in the queue, and avoid dangling TXDP pointers. Unfortunately this does not fully resolve the problem - queues still get stuck! This is similar to what ath9k does. Signed-off-by:
Bruno Randolf <br1@einfach.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
Add a counter to show how many times a queue got stuck in the debugfs queue file. Signed-off-by:
Bruno Randolf <br1@einfach.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
Since we do not know any better solution to the problem that TX queues can get stuck, this adds a timer-based watchdog, which will check for stuck queues and reset the hardware if necessary. Ported from ath9k commit 164ace38 . Signed-off-by:
Bruno Randolf <br1@einfach.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
Clearer separation between queue handling and what we do with completed frames. Signed-off-by:
Bruno Randolf <br1@einfach.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
It does not make sense to stop queues for NF calibration. This will not stop transmissions from the card, if there are queued packets. If we run out of TX buffers we need to stop all queues, not only one. Signed-off-by:
Bruno Randolf <br1@einfach.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
Take txq lock in debug file and fix reporting of used buffers. Signed-off-by:
Bruno Randolf <br1@einfach.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
Prepare ath5k for WME by using four hardware queues. The way we set up our queues matches the mac80211 queue priority 1:1, so we don't have to do any mapping for queue numbers. Every queue uses 50 of the total 200 available transmit buffers, so the DMA memory usage does not increase with this patch, but it might be good to fine-tune the number of buffers per queue later (depending on the CPU speed and load, and the speed of the medium access, it might not be big enough). Signed-off-by:
Bruno Randolf <br1@einfach.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Bob Copeland authored
This change reorganizes the main ath5k file in order to re-group related functions and remove most of the forward declarations (from 61 down to 3). This is, unfortunately, a lot of churn, but there should be no functional changes. Signed-off-by:
Bob Copeland <me@bobcopeland.com> Signed-off-by:
Bruno Randolf <br1@einfach.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
Fixing up a merge issue / concurrent development: Remove unneeded ath_crypt_caps flags, as per "ath9k_hw: remove useless hw capability flags" (364734fa ), but set the AESCCM flag for ath9k. common ath code still needs a flag for this because there is ath5k hardware which can't do AES in hardware. Signed-off-by:
Bruno Randolf <br1@einfach.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
This patch is loosely based on an ath9k patch called: "ath9k_hw: sync initvals for ar9001 and ar9002 with Atheros" It includes the following changes/fixes: - AGC setting improvements - timing changes for improved performance Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- 16 Sep, 2010 4 commits
-
-
Luis R. Rodriguez authored
The patch titled "ath9k: Add new file init.c" shuffled some code around but in dong so for some reason also removed the revision check for disablign power save. Add this revision check again so we can get power save re-enabled again by default on cards newer than AR5416 and AR5418. $ git describe --contains 55624204 v2.6.34-rc1~233^2~49^2~343 This patch has fixes for stable kernels [2.6.34+]. Cc: stable@kernel.org Cc: Paul Stewart <pstew@google.com> Cc: Amod Bodas <amod.bodas@atheros.com> Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Senthil Balasubramanian authored
The patch: commit 293dc5df Author: Gabor Juhos <juhosg@openwrt.org> Date: Fri Jun 19 12:17:48 2009 +0200 ath9k: remove ath_rx_ps_back_to_sleep helper This helper only clears the SC_OP_WAIT_FOR_{BEACON,CAB} flags. Remove it and clear these flags directly in the approptiate places instead. Changes-licensed-under: ISC Signed-off-by:
Gabor Juhos <juhosg@openwrt.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com> introduced a regression which forgot to lift the beacon flag after we received all broadcast and multicast data. This meant we never went to sleep consuming about ~650mW on idle. This pretty much broke power save completely. This patch has fixes for stable kernels [2.6.32+]. Cc: stable@kernel.org Cc: Paul Stewart <pstew@google.com> Cc: Sameer Nanda <snanda@google.com> Cc: Gabor Juhos <juhosg@openwrt.org> Cc: Amod Bodas <amod.bodas@atheros.com> Signed-off-by:
Senthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
ath9k's entire logic with SC_OP_SCANNING is incorrect due to the way mac80211 currently implements the scan complete callback and we handle it in ath9k. This patch removes the flag completely in preference for the SC_OP_OFFCHANNEL which is really what we wanted. The scanning flag was used to ensure we reset ANI to the old values when we go back to the home channel, but if we are offchannel we use some defaults. The flag was also used to re-enable the TX monitor. Without this patch we simply never re-enabled ANI and the TX monitor after going offchannel. This means that after one background scan we are prone to noise issues and if we had a TX hang we would not recover. To get this to work properly we must enable ANI after we have configured the beacon timers, otherwise hardware acts really oddly. This patch has stable fixes which apply down to [2.6.36+], there *may* be a to fix this on older kernels but requires a bit of work since this patch relies on the new mac80211 flag IEEE80211_CONF_OFFCHANNEL which was introduced as of 2.6.36. Cc: stable@kernel.org Cc: Paul Stewart <pstew@google.com> Cc: Amod Bodas <amod.bodas@atheros.com> Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
When we return to the home channel we were never reseting our beacon timers, this was casued by the fact that the scanning flag was still on even after we returned to our home channel. There are also other reasons why we would get a reset and if we are not off channel we always need to resynch our beacon timers, because a reset will clear them. This bug is a regression introduced on 2.6.36. The order of the changes are as follows: 5ee08656 - Sat Jul 31 - ath9k: prevent calibration during off-channel activity a0daa0e7 - Tue Jul 27 - Revert "mac80211: fix sw scan bracketing" 543708be - Fri Jun 18 - mac80211: fix sw scan bracketing mcgrof@tux ~/linux-2.6-allstable (git::master)$ git describe \ --contains 5ee08656 v2.6.36-rc1~43^2~34^2~22 mcgrof@tux ~/linux-2.6-allstable (git::master)$ git describe \ --contains a0daa0e7 v2.6.36-rc1~571^2~64^2~13 mcgrof@tux ~/linux-2.6-allstable (git::master)$ git describe \ --contains 543708be v2.6.36-rc1~571^2~107^2~187 So 5ee08656 would have worked if a0daa0e7 was not committed but it was so this means 5ee08656 was broken since it assumed that when we were in the channel change routine the scan flag would be lifted. As it turns out the scan flag will be set when we are already on the home channel. For more details refer to: http://code.google.com/p/chromium-os/issues/detail?id=5715 These issues will need to be considered for our solution on reshifting the scan complete callback location on mac80211 on current development kernel work. This patch has stable fixes which apply down to [2.6.36+] Cc: stable@kernel.org Cc: Paul Stewart <pstew@google.com> Cc: Amod Bodas <amod.bodas@atheros.com> Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-