- 02 6月, 2011 2 次提交
-
-
由 Fabrice Deyber 提交于
This fix ensure the timers to be set at beacon interval boundaries. Without this change timers can be set improperly resulting in the absence of beacons. Signed-off-by: NFabrice Deyber <fabricedeyber@agilemesh.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Rajkumar Manoharan 提交于
Earlier beacon_interval is used to hold interval value and some flags (ATH9K_BEACON_ENA &ATH9K_BEACON_PERIOD). So to extract interval ATH9K_BEACON_PERIOD is used. Those flags were completely removed. So masking beacon_interval is not required. Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 20 5月, 2011 4 次提交
-
-
由 Felix Fietkau 提交于
Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
rounding up the delta between last-beacon-tsf and tsf to intval is wrong and can lead to misconfigured timers which breaks beacon transmission. Fix this by adding intval and subtracting the offset of the tsf within the current slot. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
The Times They Are a-Changin'. Signed-off-by: NSujith Manoharan <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
In ad-hoc mode, beacon timers are configured differently compared to AP mode, and (depending on the scenario) can vary enough to make the beacon tasklet not detect slot 0 based on the TSF. Since staggered beacons are not (and cannot be) used in ad-hoc mode, it makes more sense to just hardcode slot 0 here, avoiding unnecessary TSF reads and calculations. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Reported-by: NRajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 11 5月, 2011 1 次提交
-
-
由 Rajkumar Manoharan 提交于
The assumsion is that while processing ath9k tasklet, interrupts were already disabled and it will be enabled at the completion of ath9k tasklet. But whenever TSFOOR is raised, the driver configures the beacon timers after having received a beacon frame from the AP which inturn enables the interrupts. Cc: stable@kernel.org Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 27 4月, 2011 1 次提交
-
-
由 Rajkumar Manoharan 提交于
Requesting beacon sync up to configure beacon timers properly in hw, has be done after doing beacon config with default values. Setting the flags in beacon config is causing the device to not enter into network sleep on idle state. Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 20 4月, 2011 1 次提交
-
-
由 Rajkumar Manoharan 提交于
While leaving the oper channel, beacon generation is stopped by mac80211 and beacon slots are marked as inactive. During the scan, ath9k configures beacon timers based on IEEE80211_CONF_OFFCHANNEL which inturn generates beacon alert even though bslot is inactive. ath9k fails to disable beacon alert while moving to offchannel if none of the beacon slot is active. This is causing beacon transmission on foreign channel. This patch enables swba based on active bslots. This issue was reported with two vifs (AP+STA) and triggered scan in STA vif in unassociated state. Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 15 4月, 2011 1 次提交
-
-
由 Rajkumar Manoharan 提交于
Request a re-configuration of Beacon related timers on the receipt of the first Beacon frame has to be set only for station mode. Setting beacon sync for IBSS is causing wrong beacon slot selection on beacon generation. Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 13 4月, 2011 1 次提交
-
-
由 Rajkumar Manoharan 提交于
The commit "ath9k: configure beacons based on hw opmode" introduced a regression which leads to kernel panic. Failed to stop ani timer during the driver unload while any of the beaconing vif is running. Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 08 4月, 2011 4 次提交
-
-
由 Rajkumar Manoharan 提交于
Current ath9k code does not handle beacon timers on opmode specific. One such example is that a STA beacon config overwrites already configured AP vif's beacon timers during scan. On multi station vif case, configure beacon timers beased on primary vif selected. This also helps while moving back to single STA vif from multi STA vifs, where the power save is enabled and hw has to be reconfigured with proper beacon and bssid/aid. Otherwise connection poll will be triggered so frequently due to beacon loss. Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Rajkumar Manoharan 提交于
Remove unused bssid from ath_vif and set av_bslot on beacon alloc/return. Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
Since the beacon timers are global, the individual vif type should not be used to determine the beacon timer configuration mode, use the global opmode instead. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
The recent cleanups in the beacon code fixed SWBA backoff calculation, however it did not remove a line of code that worked around the issues from the earlier version of the code. After the cleanup, the initial TSF based slot calculation now always returns 0 instead of ATH_BCBUF-1, so the previous hack that reversed the slot order needs to be removed, as ad-hoc mode does not use staggered beacons. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 31 3月, 2011 3 次提交
-
-
由 Felix Fietkau 提交于
Stuck beacon detection is supposed to trigger when 9 consecutive beacons could not be sent by the hardware. When the driver runs only one active AP mode interface, it still configures the hardware beacon timer for 4 (ATH_BCBUF) beacon slots slots, which causes stuck beacon detection to be reset if ath9k_hw_stoptxdma clears the stuck frames between SWBA intervals. Fix this by not resetting the missed beacon count for empty slots and multiplying the threshold not by the maximum number of beacon slots but by the configured number of beacon interfaces. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
Single missed (i.e. not transmitted) beacons in AP mode are not very rare and not necessarily an indicator of strong interference, so only trigger noise floor recalibration when multiple consecutive beacons could not be transmitted. Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
AP mode beacon timers in ath9k are configured in milliseconds, which breaks when increasing ATH_BCBUF to 8 instead of 4 (due to rounding errors). Since the hardware timers are actually configured in microseconds, it's better to let the driver use that unit directly. To be able to do that, the beacon interval parameter abuse for passing certain flags needs to be removed. This is easy to do, because those flags are completely unnecessary anyway. ATH9K_BEACON_ENA is ignored, ATH9K_BEACON_RESET_TSF can be replaced with calling ath9k_hw_reset_tsf from the driver directly. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 15 3月, 2011 1 次提交
-
-
由 Felix Fietkau 提交于
ath9k calls ath9k_hw_stoptxdma every time it sends a beacon, however there is not much point in doing that if the previous beacon and mcast traffic went out properly. On AR9380, calling that function too often can result in an increase of stuck beacons due to differences in the handling of the queue enable/disable functionality. With this patch, the queue will only be explicitly stopped if the previous data frames were not sent successfully. With the beacon code being the only remaining user of ath9k_hw_stoptxdma, this function can be simplified in order to remove the now pointless attempts at waiting for transmission completion, which would never happen at this point due to the different method of tx scheduling of the beacon queue. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 15 2月, 2011 1 次提交
-
-
由 Rajkumar Manoharan 提交于
Beaconing should be disabled before stopping beacon queue. Not doing so could queue up beacons in hw that causes failure to stop Tx DMA, due to pending frames in hw and also unnecessary beacon tasklet schedule. Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 10 2月, 2011 1 次提交
-
-
由 Steve Brown 提交于
The variable appears in both ath_softc and ath_beacon_config. The struct ath_beacon_config is embedded in ath_softc. The redundant variable was added by commit id 57c4d7b4. Signed-off-by: NSteve Brown <sbrown@cortland.com> Reviewed-by: NMohammed Shafi <shafi.ath9k@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 08 2月, 2011 1 次提交
-
-
由 Mohammed Shafi Shajakhan 提交于
Add few comments for not parsing DTIM period from mac80211 Signed-off-by: NMohammed Shafi Shajakhan <mshajakhan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 29 1月, 2011 2 次提交
-
-
由 Felix Fietkau 提交于
Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 22 1月, 2011 1 次提交
-
-
由 Felix Fietkau 提交于
When beacons are being added or removed for an interface, ieee80211_beacon_get will sometimes not return a beacon. This is normal and should not result in useless logspam. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 20 1月, 2011 1 次提交
-
-
由 Ben Greear 提交于
When using a mixture of AP and Station interfaces, the hardware mode was using the type of the last VIF registered. Instead, we should keep track of the number of different types of vifs and set the mode accordingly. In addtion, use the vif type instead of hardware opmode when dealing with beacons. Attempt to move some of the common setup code into smaller methods so we can re-use it when changing vif mode as well as adding/deleting vifs. Signed-off-by: NBen Greear <greearb@candelatech.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 05 1月, 2011 1 次提交
-
-
由 Mohammed Shafi Shajakhan 提交于
Some minor clean ups in assigning values to beacon config parameters Signed-off-by: NMohammed Shafi Shajakhan <mshajakhan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 08 12月, 2010 2 次提交
-
-
由 Joe Perches 提交于
Remove ath/debug.h and the includes of these files. Coalesce long formats. Correct a few misspellings and missing "\n"s from these logging messages. Remove unnecessary trailing space before a newline. Remove ARRAY_SIZE casts, use printf type %zu Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Joe Perches 提交于
So these errors are always emitted at KERN_ERR level. Remove ARRAY_SIZE casts, use printf type %zu Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 01 12月, 2010 1 次提交
-
-
由 Mohammed Shafi Shajakhan 提交于
This feature is to mitigate the problem of certain 3 stream chips that exceed the PCIe power requirements.An EEPROM flag controls which chips have APM enabled which is basically read from miscellaneous configuration element of the EEPROM header. This workaround will reduce power consumption by using 2 Tx chains for Single and Double stream rates (5 GHz only).All self generated frames (regardless of rate) are sent on 2 chains when this feature is enabled(Chip Limitation). Cc: Paul Shaw <paul.shaw@atheros.com> Signed-off-by: NMohammed Shafi Shajakhan <mshajakhan@atheros.com> Tested-by: NMohammed Shafi Shajakhan <mshajakhan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 18 11月, 2010 1 次提交
-
-
由 Felix Fietkau 提交于
Merge initial processing for the CAB queue and regular tx. Also move ath_tx_cabq() to beacon.c and make it static. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 16 11月, 2010 1 次提交
-
-
由 Felix Fietkau 提交于
The current ath9k tx queue handling code showed a few issues that could lead to locking issues, tx stalls due to stopped queues, and maybe even DMA issues. The main source of these issues is that in some places the queue is selected via skb queue mapping in places where this mapping may no longer be valid. One such place is when data frames are transmitted via the CAB queue (for powersave buffered frames). This is made even worse by a lookup WMM AC values from the assigned tx queue (which is undefined for the CAB queue). This messed up the pending frame counting, which in turn caused issues with queues getting stopped, but not woken again. To fix these issues, this patch removes an unnecessary abstraction separating a driver internal queue number from the skb queue number (not to be confused with the hardware queue number). It seems that this abstraction may have been necessary because of tx queue preinitialization from the initvals. This patch avoids breakage here by pushing the software <-> hardware queue mapping to the function that assigns the tx queues and redefining the WMM AC definitions to match the numbers used by mac80211 (also affects ath9k_htc). To ensure consistency wrt. pending frame count tracking, these counters are moved to the ath_txq struct, updated with the txq lock held, but only where the tx queue selected by the skb queue map actually matches the tx queue used by the driver for the frame. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Reported-by: NBjörn Smedman <bjorn.smedman@venatech.se> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 10 11月, 2010 1 次提交
-
-
由 Felix Fietkau 提交于
OProfile showed that ath9k was spending way too much time in ath9k_hw_set_interrupts. Since most of the interrupt mask changes only need to globally enable/disable interrupts, it makes sense to split this part into separate functions, replacing all calls to ath9k_hw_set_interrupts(ah, 0) with ath9k_hw_disable_interrupts(ah). ath9k_hw_set_interrupts(ah, ah->imask) only gets changed to ath9k_hw_enable_interrupts(ah), whenever ah->imask was not changed since the point where interrupts were disabled. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 26 10月, 2010 1 次提交
-
-
由 Felix Fietkau 提交于
Since aggregation is usually triggered by tx completion, a hardware reset (because of beacon stuck, tx hang or baseband hang) can significantly delay the transmission of the next AMPDU (until the next tx completion event). Fix this by rescheduling aggregation after such a reset. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Cc: stable@kernel.org Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 16 10月, 2010 2 次提交
-
-
由 Ben Greear 提交于
This doesn't fix any problem that I'm aware of, but should make it harder to add use-after-free type bugs in the future. Signed-off-by: NBen Greear <greearb@candelatech.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ben Greear 提交于
The bf_dmacontext seems to be totally useless and duplicated by bf_buf_addr. Remove it entirely, use bf_buf_addr in its place. Signed-off-by: NBen Greear <greearb@candelatech.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 17 8月, 2010 2 次提交
-
-
由 Felix Fietkau 提交于
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: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
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: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 15 6月, 2010 1 次提交
-
-
由 Felix Fietkau 提交于
Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 25 5月, 2010 1 次提交
-
-
由 Felix Fietkau 提交于
With VEOL, Beacon transmission in ad-hoc does not currently work. I believe for larger ad-hoc networks, VEOL is too unreliable, as it can get beacon transmissions stuck during synchronization. Use SWBA based beacon trasmission similar to AP mode instead. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Acked-by: NBenoit Papillault <benoit.papillault@free.fr> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-