- 14 12月, 2010 9 次提交
-
-
由 Felix Fietkau 提交于
AR*_MAX_RATE_POWER => MAX_RATE_POWER AR*_EEPROM_MODAL_SPURS => AR_EEPROM_MODAL_SPURS AR*_OPFLAGS_* => AR5416_OPFLAGS_* ... Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
Newer chips do not need this, and maybe these register writes could have negative side effects on newer hardware. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
wireless-testing commit 04caf863 ('ath9k: more tx setup cleanups') merged tx path code for HT vs non-HT frames, however it did not pass the tid pointer to ath_tx_send_normal, causing an inconsistency between AMPDU vs non-AMPDU sequence number handling. Fix this by always passing in the tid pointer for all QoS data frames. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
The HW has to be awake when accessing registers. Signed-off-by: NSujith Manoharan <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Mohammed Shafi Shajakhan 提交于
The registers TBTT_TIMER ,DMA_BEACON_ALERT ,NEXT_SWBA are need to be configured only for AP and IBSS mode. SWBA register is used for generating software interrupts so that beacon frames will be created by the software.DMA beacon alert register is to indicate the hardware to DMA the contents of beacon buffer to PCU buffer and TBTT to start transmitting the packet buffer to the base band. Clearly these things are not needed for station/monitor mode so remove configuring them. Cc: doug dahlby <ddahlby@atheros.com> Signed-off-by: NMohammed Shafi Shajakhan <mshajakhan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Rajkumar Manoharan 提交于
key4 of micentry is used, if ATH_CRYPT_CAP_MIC_COMBINED is set. But is not cleared on key cache reset. Cc: stable@kernel.org Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Rajkumar Manoharan 提交于
Add support to change interface type without bringing down the interface. Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
mac80211 will notify drivers when to go idle and ath9k assumed that it would get further notifications for idle states after a device stop() config call but as per agreed semantics the idle state of the radio is left up to driver after mac80211 issues the stop() callback. The driver is resposnbile for ensuring the device remains idle after that even between suspend / resume calls. This fixes suspend/resume when you issue suspend and resume twice on ath9k when ath9k_stop() was already called. We need to put the radio to full sleep in order for resume to work correctly. What might seem fishy is we are turning the radio off after resume. The reason why we do this is because we know we should not have anything enabled after a mac80211 tells us to stop(), if we resume and never get a start() we won't get another stop() by mac80211 so to be safe always bring the 802.11 device with the radio disabled after resume, this ensures that if we suspend we already have the radio disabled and only a start() will ever trigger it on. Cc: stable@kernel.org Cc: Paul Stewart <pstew@google.com> Cc: Amod Bodas <amod.bodas@atheros.com> Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
Upon a failure we never call ath9k_ps_restore() on ath_radio_enable(), this will throw off the sc->ps_usecount. When the sc->ps_usecount is > 0 we never put the chip to full sleep. This drains battery, and will also make the chip fail upon resume with: ath: Starting driver with initial channel: 5745 MHz ath: timeout (100000 us) on reg 0x7000: 0xdeadbeef & 0x00000003 != 0x00000000 This would make the chip useless upon resume. I cannot prove this can happen but in theory it is so best to avoid this race completely and not have users complain about a broken device after resume. Cc: stable@kernel.org Cc: Paul Stewart <pstew@google.com> Cc: Amod Bodas <amod.bodas@atheros.com> Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 09 12月, 2010 9 次提交
-
-
由 John W. Linville 提交于
Description by Hauke: "If CONFIG_ATH_DEBUG=y is set ATH_DBG_WARN_ON_ONCE uses WARN_ON_ONCE and returns something, but if CONFIG_ATH_DEBUG is not set it does not return anything. Now ATH_DBG_WARN_ON_ONCE is used in the boolean expression in an if case and is not returning anything and causes a compile error. CC [M] /drivers/net/wireless/ath/ath9k/main.o /drivers/net/wireless/ath/ath9k/main.c: In function ‘ath_isr’: /drivers/net/wireless/ath/ath9k/main.c:769: error: expected expression before ‘do’ make[5]: *** [/drivers/net/wireless/ath/ath9k/main.o] Error 1 make[4]: *** [/drivers/net/wireless/ath/ath9k] Error 2" Reported-by: NHauke Mehrtens <hauke@hauke-m.de> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sedat Dilek 提交于
The AHB bus support patchset moved the table "Known PCI ids" from base.c to pci.c - unfortunately, MODULE_DEVICE_TABLE() was not transferred. With this fix 'modinfo ath5k' lists the alias -> pci-id lines, again. The issue was introduced by: commit e5b046d8 "ath5k: Move PCI bus functions to separate file." Signed-off-by: NSedat Dilek <sedat.dilek@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
Suspend requires the device to be in fullsleep otherwise upon resume the device becomes unresponsive. We need to ensure that when we want the device to go to sleep it yields to the request, otherwise we'll have a useless devices upon resume. Warn when changing the power fails as we need to look into these issues. Cc: Paul Stewart <pstew@google.com> Cc: Amod Bodas <amod.bodas@atheros.com> Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
We should not be idle when we get the ATH9K_INT_TIM_TIMER, otherwise its a sign of something broken in our design with our idle state machine and mac80211. Skip these and WARN once just in case this is triggerable. Cc: Paul Stewart <pstew@google.com> Cc: Amod Bodas <amod.bodas@atheros.com> signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ben Greear 提交于
It can be NULL according to docs, and logging showed it to be NULL in practice. Signed-off-by: NBen Greear <greearb@candelatech.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
The HW has to be set to FULLSLEEP mode during suspend, when no interface has been brought up. Not doing this would break resume, as the chip won't be powered up at all. Signed-off-by: NSujith Manoharan <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Javier Cardona 提交于
Signed-off-by: NJavier Cardona <javier@cozybit.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Javier Cardona 提交于
This results in an erroneus num_adhoc_vifs count, as the this counter was incremented but not decremented for mesh interfaces. Signed-off-by: NJavier Cardona <javier@cozybit.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Javier Cardona 提交于
This patch fixes the oops below when attempting to bring up a mesh interface on ath5k hardware. [ 128.933099] kernel BUG at drivers/net/wireless/ath/ath5k/base.c:197! [ 128.933099] invalid opcode: 0000 [#1] (...) [ 128.933099] Call Trace: [ 128.933099] [<c83b77fa>] ? ath5k_beacon_update+0x57/0x1f8 [ath5k] [ 128.933099] [<c02d9a40>] ? __sysfs_add_one+0x28/0x76 [ 128.933099] [<c83b830e>] ? ath5k_bss_info_changed+0x13f/0x173 [ath5k] [ 128.933099] [<c82ff629>] ? ieee80211_config_beacon+0xc0/0x17e [mac80211] [ 128.933099] [<c82f073e>] ? ieee80211_bss_info_change_notify+0x182/0x18b [mac80211] [ 128.933099] [<c83b81cf>] ? ath5k_bss_info_changed+0x0/0x173 [ath5k] [ 128.933099] [<c82ff6d6>] ? ieee80211_config_beacon+0x16d/0x17e [mac80211] [ 128.933099] [<c82ff753>] ? ieee80211_add_beacon+0x34/0x39 [mac80211] [ 128.933099] [<c830a4ed>] ? ieee80211s_init+0xf8/0x10f [mac80211] [ 128.933099] [<c830a5df>] ? ieee80211_mesh_init_sdata+0xdb/0x154 [mac80211] Signed-off-by: NJavier Cardona <javier@cozybit.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 08 12月, 2010 22 次提交
-
-
由 Mohammed Shafi Shajakhan 提交于
The structure struct ieee80211_rx_status *rxs is no longer needed to be passed to ath_rx_send_to_mac80211 function Signed-off-by: NMohammed Shafi Shajakhan <mshajakhan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Mohammed Shafi Shajakhan 提交于
With the current save power save implementation we assume a dtim period of 1.This value is assigned based on a sanity check in the driver eventhough we had not parsed it from mac80211.This patch obtains the actual DTIM period from AP by parsing it from mac80211.Yet for handling multicast traffic we may still have it as fixed rather than parsing it from mac80211 .This does not breaks power save or anything as the sleep duration is currently fixed in the driver.This patch may serve to improve power save in the future by using dtim period for sleep duration and using correct dtim period adhoc mode. Signed-off-by: NMohammed Shafi Shajakhan <mshajakhan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Mohammed Shafi Shajakhan 提交于
AUTOSLEEP feature is enabled only for AR9271 and AR9003 version chipsets.So unlikely macro should be used only to check whether auto-sleep feature is enabled Signed-off-by: NMohammed Shafi Shajakhan <mshajakhan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
Use the correct error condition exit in case firmware download fails for some reason. Not doing so results in a panic: usb 1-3: ath9k_htc: Transferred FW: ar9271.fw, size: 51280 usb 1-3: ath9k_htc: Firmware - ar9271.fw download failed usb 1-3: ath9k_htc: Target is unresponsive Failed to initialize the device INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. Pid: 2823, comm: insmod Tainted: G W 2.6.37-rc4-wl #11 Call Trace: [<ffffffff81090d7e>] __lock_acquire+0xe3e/0x1d00 [<ffffffff813a9f14>] ? restore_args+0x0/0x30 [<ffffffff81058af1>] ? vprintk+0x321/0x500 [<ffffffff81092290>] lock_acquire+0xa0/0x190 [<ffffffffa02a0eac>] ? usb_kill_anchored_urbs+0x1c/0x80 [usbcore] [<ffffffff813a8ea8>] _raw_spin_lock_irq+0x48/0x60 [<ffffffffa02a0eac>] ? usb_kill_anchored_urbs+0x1c/0x80 [usbcore] [<ffffffff813a53fd>] ? printk+0x3c/0x3f [<ffffffffa02a0eac>] usb_kill_anchored_urbs+0x1c/0x80 [usbcore] [<ffffffffa0055388>] ath9k_hif_usb_dealloc_urbs+0x18/0x40 [ath9k_htc] [<ffffffffa00557d7>] ath9k_hif_usb_probe+0x227/0x3d0 [ath9k_htc] [<ffffffffa02a56ac>] usb_probe_interface+0x10c/0x210 [usbcore] [<ffffffff812ae826>] driver_probe_device+0x96/0x1c0 [<ffffffff812ae9f3>] __driver_attach+0xa3/0xb0 [<ffffffff812ae950>] ? __driver_attach+0x0/0xb0 [<ffffffff812ad6ae>] bus_for_each_dev+0x5e/0x90 [<ffffffff812ae4c9>] driver_attach+0x19/0x20 [<ffffffff812ae038>] bus_add_driver+0x168/0x320 [<ffffffff812aec71>] driver_register+0x71/0x140 [<ffffffff811fc338>] ? __raw_spin_lock_init+0x38/0x70 [<ffffffffa02a438c>] usb_register_driver+0xdc/0x190 [usbcore] [<ffffffffa0063000>] ? ath9k_htc_init+0x0/0x4f [ath9k_htc] [<ffffffffa005599e>] ath9k_hif_usb_init+0x1e/0x20 [ath9k_htc] [<ffffffffa006302b>] ath9k_htc_init+0x2b/0x4f [ath9k_htc] [<ffffffff8100212f>] do_one_initcall+0x3f/0x180 [<ffffffff8109ef9b>] sys_init_module+0xbb/0x200 [<ffffffff8100bf52>] system_call_fastpath+0x16/0x1b Signed-off-by: NSujith Manoharan <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
Signed-off-by: NSujith Manoharan <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith Manoharan 提交于
ath.ko is a common module shared between ath5k, ar9170usb, ath9k and ath9k_htc. Adding driver specific data to the shared structure would impact all the drivers. Handling USB device recognition for devices specific to ath9k_htc can be handled within the driver itself. Also, AR7010 refers to the processor used in both AR9280/AR9287 based devices. Rename the device enumerations accordingly. While at it, check properly for the bus type when choosing the EEPROM base address for UB95. Signed-off-by: NSujith Manoharan <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Bruno Randolf 提交于
One thing I missed in my WME series: Older hardware does not have enough hardware queues to support WME. In this case we just set up one data queue. Use the capability information to decide how many queues to set up. Signed-off-by: NBruno Randolf <br1@einfach.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ben Greear 提交于
This decreases spammage in the log. A single line message will still be printed, so users can be aware that problem exists. Signed-off-by: NBen Greear <greearb@candelatech.com> Acked-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
Right now it is done for only AR9485, will be done for ar9003 also after proper testing. Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
Also spur channel count and range is different for AR9485. Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
This helper function would be used for AR9485. Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-