- 24 6月, 2010 1 次提交
-
-
由 Vivek Natarajan 提交于
Some vendors require the LED to be ON always irrespective of any radio activity. Introducing a module parameter to disable blinking, so that one can choose between always on or led blink during activity. Signed-off-by: NVivek Natarajan <vnatarajan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 15 6月, 2010 6 次提交
-
-
由 Felix Fietkau 提交于
replace calls that read this capability with accesses to ath9k_hw's regulatory data. 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: NLuis R. Rodriguez <lrodriguez@atheros.com> 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>
-
由 Felix Fietkau 提交于
Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
This adds support for ANI for AR9003. The implementation for ANI for AR9003 is slightly different than the one used for the older chipset families. It can technically be used for the older families as well but this is not yet fully tested so we only enable the new ANI for the AR5008, AR9001 and AR9002 families with a module parameter, force_new_ani. The old ANI implementation is left intact. Details of the new ANI implemention: * ANI adjustment logic is now table driven so that each ANI level setting is parameterized. This makes adjustments much more deterministic than the old procedure based logic and allows adjustments to be made incrementally to several parameters per level. * ANI register settings are now relative to INI values; so ANI param zero level == INI value. Appropriate floor and ceiling values are obeyed when adjustments are combined with INI values. * ANI processing is done once per second rather that every 100ms. The poll interval is now a set upon hardware initialization and can be picked up by the core driver. * OFDM error and CCK error processing are made in a round robin fashion rather than allowing all OFDM adjustments to be made before CCK adjustments. * ANI adjusts MRC CCK off in the presence of high CCK errors * When adjusting spur immunity (SI) and OFDM weak signal detection, ANI now sets register values for the extension channel too * When adjusting FIR step (ST), ANI now sets register for FIR step low too * FIR step adjustments now allow for an extra level of immunity for extremely noisy environments * The old Noise immunity setting (NI), which changes coarse low, size desired, etc have been removed. Changing these settings could affect up RIFS RX as well. * CCK weak signal adjustment is no longer used * ANI no longer enables phy error interrupts; in all cases phy hw counting registers are used instead * The phy error count (overflow) interrupts are also no longer used for ANI adjustments. All ANI adjustments are made via the polling routine and no adjustments are possible in the ISR context anymore * A history settings buffer is now correctly used for each channel; channel settings are initialized with the defaults but later changes are restored when returning back to that channel * When scanning, ANI is disabled settings are returned to (INI) defaults. * OFDM phy error thresholds are now 400 & 1000 (errors/second units) for low/high water marks, providing increased stability/hysteresis when changing levels. * Similarly CCK phy error thresholds are now 300 & 600 (errors/second) Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
Allow drivers to sleep, and indicate this in the documentation. ath9k has some locking I don't understand, so keep it safe and disable BHs in it, all other drivers look fine with the context change. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 04 6月, 2010 2 次提交
-
-
由 Felix Fietkau 提交于
Because there is a limited number of tx buffers available, once the queue has been filled to a certain point, ath9k needs to stop accepting new frames from mac80211. In order to prevent a full WMM queue from stopping another queue with fewer frames, this patch limits the number of queued frames to a quarter of the total available tx buffers, minus some reserved frames to be used for other purposes (e.g. beacons). Because tx buffers are reserved for frames when they're staged in software queues as well, the actual queue depth cannot be used for this, so this patch stores a reference to the tx queue in the ath_buf struct and keeps track of the total number of pending frames. 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>
-
- 03 6月, 2010 2 次提交
-
-
Rx should not be disabed/disabled when hw supports auto sleeping. Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
This enables the baseband watchdog events for the AR9003 family on ath9k. Upon an a baseband watchdog interrupt we reset the hardware, this should address corner case conditions where normal operation can stall. Enable ATH_DBG_RESET to be able to review details of the bb watchdog interrupt once it happens. If you're curious how often this happens just grep the debugfs interrupt file. Cc: Sam Ng <sam.ng@atheros.com> Cc: Paul Shaw <paul.shaw@atheros.com> Cc: Don Breslin <don.breslin@atheros.com> Cc: Cliff Holden <cliff.holden@atheros.com Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 25 5月, 2010 1 次提交
-
-
由 John W. Linville 提交于
This reverts commit 03ceedea. This patch was reported to cause a regression in which connectivity is lost and cannot be reestablished after a suspend/resume cycle. Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 29 4月, 2010 1 次提交
-
-
由 Benoit Papillault 提交于
Signed-off-by: NBenoit Papillault <benoit.papillault@free.fr> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 20 4月, 2010 2 次提交
-
-
由 Felix Fietkau 提交于
Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Daniel Yingqiang Ma 提交于
When I set up multiple VAPs with ath9k, I encountered an issue that the traffic may be lost after a while. The detailed phenomenon is 1. After a while the clients connected to one of these VAPs will get into a state that no broadcast/multicast packets can be transfered successfully while the unicast packets can be transfered normally. 2. Minutes latter the unitcast packets transfer will fail as well, because the ARP entry is expired and it can't be freshed due to the broadcast trouble. It's caused by the group key overwritten and someone discussed this issue in ath9k-devel maillist before, but haven't work out a fix yet. I referred the method in madwifi, and made a patch for ath9k. The method is to set the high bit of the sender(AP)'s address, and associated that mac and the group key. It requires the hardware supports multicast frame key search. It seems true for AR9160. Not sure whether it's the correct way to fix this issue. But it seems to work in my test. The patch is attached, feel free to revise it. Signed-off-by: NDaniel Yingqiang ma <yma.cool@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 17 4月, 2010 3 次提交
-
-
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> 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: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 07 4月, 2010 2 次提交
-
-
由 Pavel Roskin 提交于
Add ah variable in the functions that didn't have it and used sc->imask. Replace sc->sc_ah with ah in those functions. Signed-off-by: NPavel Roskin <proski@gnu.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
With the enable_radio being uninitialized, ath_radio_enable() might be called twice, which can leave some hardware in an undefined state. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Cc: stable@kernel.org Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 20 2月, 2010 1 次提交
-
-
由 Johannes Berg 提交于
This converts ath9k to use the new station add/remove callbacks instead of using the old sta_notify callback. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 09 2月, 2010 2 次提交
-
-
由 Ming Lei 提交于
If split tkip key is used, ath_delete_key should delete rx key and rx mic key. This patch fixes the leak of hw keycache in the case. Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Senthil Balasubramanian 提交于
The TIM timer interrupt is enabled even before the ACK of nullqos is received which is unnecessary. Also clean up the CONF_PS part of config callback properly for better readability. Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 02 2月, 2010 1 次提交
-
-
由 Pavel Roskin 提交于
Numeric channel is hard to get, so it won't be printed. Replace Mhz with MHz on the affected lines and add commas as needed. Signed-off-by: NPavel Roskin <proski@gnu.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 29 1月, 2010 1 次提交
-
-
由 Vivek Natarajan 提交于
IDLE PS (Full Sleep) doesn't work when ifconfig up is done during Idle unassociated state. Fix this by restoring FULL SLEEP in ps_restore if CONF_IDLE is set. Signed-off-by: NVivek Natarajan <vnatarajan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 20 1月, 2010 2 次提交
-
-
由 Felix Fietkau 提交于
When cleaning up beacon buffers and slots, ath9k currently checks if sc->ah->opmode is set to a beacon related mode before cleaning up buffers. An unfortunate ordering of interface up/down commands can lead to sc->ah->opmode being set to monitor mode, while there are AP interfaces present on the same wiphy. Always cleaning up beacon buffers if present fixes this issue. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Cc: stable@kernel.org Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
Users wishing to tweak tx power want it to happen immediately, try to respect that. This was tested by Lorenzo by measuring the received signal strength from an AP with ath9k and the patch. Changing the tx power on the AP produced these results: 1) iwconfig wlan0 txpower 20 ---> Rx power -37dbm 2) iwconfig wlan0 txpower 15 ---> Rx power -41dbm 3) iwconfig wlan0 txpower 10 ---> Rx power -45dbm 4) iwconfig wlan0 txpower 5 ---> Rx power -51dbm 5) iwconfig wlan0 txpower 0 ---> Rx power -37dbm The result with 0 is an anomoly and would need to be addressed through a separate patch. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Tested-by: NLorenzo Bianconi <lorenzo.bianconi83@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 16 1月, 2010 2 次提交
-
-
由 Felix Fietkau 提交于
Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
Previously ath9k left the initialization of slot timing and ACK/CTS timeout to the mode specific initvals. This does not handle short vs long slot in 2.4 GHz and uses a rather strange value for the 2.4 GHz ACK timeout (64 usec). This patch uses the proper ath9k_hw functions for setting slot time and timeouts and also implements the switch between short and long slot time in 2.4 GHz Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 13 1月, 2010 6 次提交
-
-
由 Sujith 提交于
mac80211 passes appropriate flags indicating whether monitor mode is being used. Use this to set the HW opmode. Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith 提交于
The TX queues have to be stopped during an internal reset. Not handling this would result in packet loss - fix this. Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith 提交于
sc_flags has slowly become a kitchen sink over time. Move powersave related flags to a separate variable. Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith 提交于
Move initialization/de-initialization related code to this file. Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith 提交于
Move all LED/RFKILL/BTCOEX related code to gpio.c Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
The newer single chip hardware family of chipsets have not been experiencing issues with power saving set by default with recent fixes merged (even into stable). The remaining issues are only reported with AR5416 and since enabling PS by default can increase power savings considerably best to take advantage of that feature as this has been tested properly. For more details on this issue see the bug report: http://bugzilla.kernel.org/show_bug.cgi?id=14267 We leave AR5416 with PS disabled by default, that seems to require some more work. Cc: stable@kernel.org Cc: Peter Stuge <peter@stuge.se> Cc: Justin P. Mattock <justinmattock@gmail.com> Cc: Kristoffer Ericson <kristoffer.ericson@gmail.com> Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 29 12月, 2009 4 次提交
-
-
由 Johannes Berg 提交于
All its members (vif, mac_addr, type) are now available in the vif struct directly, so we can pass that instead of the conf struct. I generated this patch (except the mac80211 and header file changes) with this semantic patch: @@ identifier conf, fn, hw; type tp; @@ tp fn(struct ieee80211_hw *hw, -struct ieee80211_if_init_conf *conf) +struct ieee80211_vif *vif) { <... ( -conf->type +vif->type | -conf->mac_addr +vif->addr | -conf->vif +vif ) ...> } Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
AMDPDU actions poke hardware for TX operation, as such we want to turn hardware on for these actions. AMDPU RX operations do not require hardware on as nothing is done in hardware for those actions. Without this we cannot guarantee hardware has been programmed correctly for each AMPDU TX action. Cc: stable@kernel.org Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
When we remove a IBSS/AP/Mesh interface we stop DMA but to do this we should ensure hardware is on. Awaken the device prior to these calls. This should ensure DMA is stopped upon suspend and plain device removal. Cc: stable@kernel.org Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith 提交于
Ensure the device is awake prior to trying to tell hardware to stop it. Impact of not doing this is we can likely leave the device in an undefined state likely causing issues with suspend and resume. This patch ensures harware is where it should be prior to suspend. Cc: stable@kernel.org Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 23 12月, 2009 1 次提交
-
-
由 Sujith 提交于
Disable the TX hang monitoring routine when doing a scan. Monitoring for a hung situation is not really necessary during a scan run. Cc: stable@kernel.org Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-