- 15 Nov, 2010 28 commits
-
-
Rafał Miłecki authored
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rafał Miłecki authored
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Stanislaw Gruszka authored
Currently we are canceling scan when changing BSSID. Behave the same when changing association and beacon enablement, to avoid committing rxon during scan in iwl_set_no_assoc(). Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Stanislaw Gruszka authored
Do not set power mode when scanning, and defer that when scan finish. We still set power mode in force case i.e. when device is overheated. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Stanislaw Gruszka authored
Avoid sending commands to firmware (including commit_rxon) when scan is pending and we are calling iwlagn_bt_traffic_change_work simultaneously. Also comment some innocent race conditions. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Stanislaw Gruszka authored
Almost anywhere in the code we avoid committing rxon while performing scan, and make rxon commit when scan complete. However in some places in the code we do not follow that rule. This patch fix that problem in iwlagn_configure_filter(). Since we do not commit directly in iwl3945_configure_filter, we can also do the same for agn, so I just remove iwlcore_commit_rxon() function and add a comment. Also change comment for iwl3945. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Stanislaw Gruszka authored
According to comment in iwl_bg_scan_completed, setting tx power should be deferred during pending scan, but we are not doing this. This patch change code to really defer setting tx power after scan complete. Additionally refactor iwl_set_tx_power code and call lib->send_tx_power() directly from iwlagn_commit_rxon. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Stanislaw Gruszka authored
On 5xxx and 6xxx change to send tx_power_cmd command synchronously, to do not start other commands when setting tx power is pending. We currently do the same for 4956 and 3945. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Stanislaw Gruszka authored
Add WARN_ONCE when scanning is pending. Use STATUS_SCAN_HW bit since we can have scan canceled or completed but STATUS_SCANNING bit still set. v1 -> v2: replace EIO to EAGAIN Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
- reduce the number of retransmission attempts for sample rates - sample lower rates less often - do not use RTS/CTS for sampling frames - increase the time between sampling attempts Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
According to documentation, AR_ExcessiveRetries, AR_Filtered and AR_FIFOUnderrun are only valid if AR_FrmXmitOK is clear. Not checking this might result in suboptimal FIFO settings, unnecessary retransmissions, or other connectivity issues. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Cc: stable@kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
We have seen several DMA races when we race against stopping and starting the PCU. I suspect that when we cannot stop the PCU we may hit some of these same races so warn against them for now but only when debugging (CONFIG_ATH_DEBUG) is enabled. If you run into this warning and are a developer, please fix the cause of the warning. The potential here, although I cannot prove yet, is that the DMA engine can be confused and start writing to a buffer that was already DMA'd before and at least the kernel assumes is not being accessed by hardware anymore. Cc: Ben Greear <greearb@candelatech.com> Cc: Kyungwan Nam <kyungwan.nam@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
To be used to throw out warnings only for developers. This can be used by some corner cases that developers already know can be hit but developers want to address so to avoid spewing out a warning this can only be enabled with CONFIG_ATH_DEBUG enabled. Cc: Ben Greear <greearb@candelatech.com> Cc: Kyungwan Nam <kyungwan.nam@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
Everyone's doing it, its the cool thing. Cc: Easwar Krishnan <easwar.krishnan@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
In the worst case you are seeing really odd things you want more information than what is provided right now, for those that insist and want debug info through CONFIG_CFG80211_REG_DEBUG provide a print of when we are processing a channel and with what regulatory rule. Cc: Easwar Krishnan <easwar.krishnan@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
Cc: Easwar Krishnan <easwar.krishnan@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
This can help with debugging issues. You will only see these with CONFIG_CFG80211_REG_DEBUG enabled. Cc: Easwar Krishnan <easwar.krishnan@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
After a module loads you will have loaded the world roaming regulatory domain or a custom regulatory domain. Further regulatory hints are welcomed and should be respected unless the regulatory hint is coming from a country IE as the IEEE spec allows for a country IE to be a subset of what is allowed by the local regulatory agencies. So disable all channels that do not fit a regulatory domain sent from a unless the hint is from a country IE and the country IE had no information about the band we are currently processing. This fixes a few regulatory issues, for example for drivers that depend on CRDA and had no 5 GHz freqencies allowed were not properly disabling 5 GHz at all, furthermore it also allows users to restrict devices further as was intended. If you recieve a country IE upon association we will also disable the channels that are not allowed if the country IE had at least one channel on the respective band we are procesing. This was the original intention behind this design but it was completely overlooked... Cc: David Quan <david.quan@atheros.com> Cc: Jouni Malinen <jouni.malinen@atheros.com> cc: Easwar Krishnan <easwar.krishnan@atheros.com> Cc: stable@kernel.org Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
We should be enabling country IE hints for WIPHY_FLAG_STRICT_REGULATORY even if we haven't yet recieved regulatory domain hint for the driver if it needed one. Without this Country IEs are not passed on to drivers that have set WIPHY_FLAG_STRICT_REGULATORY, today this is just all Atheros chipset drivers: ath5k, ath9k, ar9170, carl9170. This was part of the original design, however it was completely overlooked... Cc: Easwar Krishnan <easwar.krishnan@atheros.com> Cc: stable@kernel.org Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
This is required later. Cc: Easwar Krishnan <easwar.krishnan@atheros.com> Cc: stable@kernel.org signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Stephen Hemminger authored
The following code is defined but never used. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Larry Finger authored
MMIO log traces obtained using the Broadcom wl hybrid driver show that the RETRY_TIMEOUT register (0x41) in PCI configuration space is cleared if non-zero. Similar code found in other drivers such as ipw2100 show this operation is needed to keep PCI Tx retries from interfering with C3 CPU state. There are no known cases where omission of this code has caused a problem, but this patch is offered just in case such a situation occurs. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
This fixes this sparse warning: CHECK drivers/net/wireless/ath/ath5k/base.c drivers/net/wireless/ath/ath5k/base.c:569:6: warning: symbol 'ath5k_update_bssid_mask_and_opmode' was not declared. Should it be static? Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
This fixes this sparse warning: CHECK drivers/net/wireless/ath/key.c drivers/net/wireless/ath/key.c:110:6: warning: symbol 'ath_hw_set_keycache_entry' was not declared. Should it be static? Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
This fixes this sparse warning: CHECK drivers/net/wireless/ath/key.c drivers/net/wireless/ath/key.c:70:6: warning: symbol 'ath_hw_keysetmac' was not declared. Should it be static? Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> 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
ath9k_hw_set_txpowerlimit gets an extra boolean parameter that - if set - causes the rate txpower table and the regulatory limit to be calculated and stored, without changing hardware registers. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
The same is done for the older chip families as well. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
- 09 Nov, 2010 12 commits
-
-
Bruno Randolf authored
Include the channel utilization (busy, rx, tx) in the survey results. Signed-off-by: Bruno Randolf <br1@einfach.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
Similar to Felix Fietkau <nbd@openwrt.org> "ath9k_hw: optimize all descriptor access functions" (13db2a80244908833502189a24de82a856668b8a). Signed-off-by: Bruno Randolf <br1@einfach.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Mohammed Shafi Shajakhan authored
With the current rate control selection method the median function is nowhere used, so remove it. Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
Because all of the descriptor data structures are marked as __packed, GCC assumes the worst case wrt. alignment and generates unaligned load/store instructions on MIPS for access to all fields. Since descriptors always have to be 4-byte-aligned, we can just mark the data structures with __aligned(4), which allows GCC to generate much more efficient code. Verified through disassembly and OProfile comparisons. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Rafael J. Wysocki authored
The ath9k driver uses the legacy PCI power management (suspend and resume) callbacks that apparently cause intermittent problems to happen (the adapter sometimes doesn't resume correctly on my Acer Ferrari One). Make it use the new PCI PM and let the PCI core code handle the PCI-specific details of power transitions. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
This fixes this sparse complaint: CHECK drivers/net/wireless/ath/ath9k/debug.c drivers/net/wireless/ath/ath9k/debug.c:548:34: warning: symbol 'aphy' shadows an earlier one drivers/net/wireless/ath/ath9k/debug.c:491:26: originally declared here Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
It is now only used in hw.c Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
When the timer_next argument to ath9k_gen_timer_start is behind the tsf value, tsf + timer_period is used, which is what ath_btcoex_period_timer was setting it to. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
ANI needs the RSSI average only in station mode, and only for tracking the signal strength of beacons of the AP that it is connected to. Adjust the code to track on the beacon RSSI, and store the average of that in the ath_wiphy struct. With these changes, we can get rid of this extra station lookup in the rx path, which saves precious CPU cycles. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
Disassembly shows, that at least on MIPS, the compiler generates a lot of memory accesses to the same location in the descriptor field parsing. Since it is operating on uncached memory, this can be quite expensive in this hot path. Change the code a bit to help the compiler optimize it properly, and get rid of some unused fields in the ath_tx_status struct. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
ah->config.rx_intr_mitigation does not need to be checked before checking the rx interrupt mask for AR_ISR_RXMINTR or AR_ISR_RXINTM, as those interrupts will be masked out if rx interrupt mitigation is disabled. Avoid reading AR_ISR_S5_S twice by reordering the code to be more concise. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
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: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-