- 17 4月, 2010 23 次提交
-
-
* Set rx buf size in register 0x60 * Set rxdp on the respective hw rx queue (HP and LP queues) * Process rx descriptor Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NFelix Fietkau <nbd@openwrt.org> 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>
-
HP & LP queue depth and rx status length. Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
AR9003 supports extended DMA (EDMA), this comes with some bells and whistles on top of the legacy DMA that we are used to. Mark AR9003 and later chips EDMA capable. 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>
-
由 Luis R. Rodriguez 提交于
ANI is still being debugged on AR9003 by our systems team so it should not yet be enabled yet. When ANI will be enabled all ANI functionality is expected to be enabled so fill the ANI functionality to all for AR9003 for now as well. Cc: Enis Akay <Enis.Akay@atheros.com> Signed-off-by: NLuis R. Rodriguez <lrodriguez@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>
-
由 Luis R. Rodriguez 提交于
This allows us to add SREV checks on these helpers. 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>
-
由 Luis R. Rodriguez 提交于
This add stubs for PHY support for the AR9003 hardware family. 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>
-
由 Senthil Balasubramanian 提交于
Also, clean up and reorganize the AR9287 macro to have better ordering. We won't add the PCI ID to the supported device list until we have some functional code for it. Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
The PLL control computation used to program the AR_RTC_PLL_CONTROL register varies between our harware so just add a private callback for it. AR9003 will use its own callback. Signed-off-by: NLuis R. Rodriguez <lrodriguez@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>
-
由 Luis R. Rodriguez 提交于
This is not required for the AR9003 family. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
The PHY split is easier done in a few steps. First move the RF ops to the private ops and rename them accordingly. We split PHY stuff up first for the AR5008 and AR9002 families. There are some callbacks that AR9002 share with the AR5008 familiy so we set those first, if AR9002 has some different callbacks it will override them upon hardware init. 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>
-
由 Luis R. Rodriguez 提交于
This is used only once by ath9k_hw_process_ini() to write an array of phy registers through REG_WRITE_ARRAY(), but we already call REG_WRITE_ARRAY() multiple times on the same caller so just remove this pointless wrapper. We'll eventually just move the ath9k_hw_process_ini() caller as an callback to abstract away between different hardware families. Although this change is subtle I should note that this does change the delay pattern on writing the next series of registers. REG_WRITE_ARRAY() uses a counter for each register write and does a udelay(1) every 64 writes. By removing this call it means that the counter is processed for all the iniBB_RfGain registers and is incremented on ath9k_hw_process_ini(), before this the after the call ath9k_hw_write_regs() was made the register counter was kept at the same index number prior to the call. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
AR9003 does not have a reset control for AHB. 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: 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 提交于
This is not a stable code fix as this register is not used anywhere. 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>
-
由 Felix Fietkau 提交于
AR9300 will be the first device supported of the AR9003 family. AR9300 1.0 hardware exists but it is not going to be sold anywhere so we completely skip its support. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
ath9k supports the AR5008, AR9001 and AR9002 family of Atheros chipsets, all 802.11n. The new breed of 802.11n chips, the AR9003 family will be supported as well soon. To help with its support we're going to add a few callbacks for hardware routines which differ considerably instead of adding branch checks for the revision at runtime. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 15 4月, 2010 7 次提交
-
-
由 Christian Lamparter 提交于
This patch adds the following 5 entries to the usbid device table: * Netgear WNA1000 * Proxim ORiNOCO Dual Band 802.11n USB Adapter * 3Com Dual Band 802.11n USB Adapter * H3C Dual Band 802.11n USB Adapter * WNC Generic 11n USB dongle CC: <stable@kernel.org> Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ming Lei 提交于
This patch fixes two warnings below after unplugging ar9271 usb device: -one is a kernel warning[1] -another is a lockdep warning[2] The root reason is that __skb_queue_purge can't be executed in hardirq context, so the patch forks ath9k_skb_queue_purge(ath9k version of _skb_queue_purge), which frees skb with dev_kfree_skb_any which can be run in hardirq context safely, then prevent the lockdep warning and kernel warning after unplugging ar9271 usb device. [1] kernel warning [ 602.894005] ------------[ cut here ]------------ [ 602.894005] WARNING: at net/core/skbuff.c:398 skb_release_head_state+0x71/0x87() [ 602.894005] Hardware name: 6475EK2 [ 602.894005] Modules linked in: ath9k_htc ath9k ath9k_common ath9k_hw ath bridge stp llc sunrpc ipv6 cpufreq_ondemand acpi_cpufreq freq_table kvm_intel kvm arc4 ecb mac80211 snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep thinkpad_acpi snd_pcm snd_timer hwmon iTCO_wdt snd e1000e pcspkr i2c_i801 usbhid iTCO_vendor_support wmi cfg80211 yenta_socket rsrc_nonstatic pata_acpi snd_page_alloc soundcore uhci_hcd ohci_hcd ehci_hcd usbcore i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: ath] [ 602.894005] Pid: 2506, comm: ping Tainted: G W 2.6.34-rc3-wl #20 [ 602.894005] Call Trace: [ 602.894005] <IRQ> [<ffffffff8104a41c>] warn_slowpath_common+0x7c/0x94 [ 602.894005] [<ffffffffa022f398>] ? __skb_queue_purge+0x43/0x4a [ath9k_htc] [ 602.894005] [<ffffffff8104a448>] warn_slowpath_null+0x14/0x16 [ 602.894005] [<ffffffff813269c1>] skb_release_head_state+0x71/0x87 [ 602.894005] [<ffffffff8132829a>] __kfree_skb+0x16/0x81 [ 602.894005] [<ffffffff813283b2>] kfree_skb+0x7e/0x86 [ 602.894005] [<ffffffffa022f398>] __skb_queue_purge+0x43/0x4a [ath9k_htc] [ 602.894005] [<ffffffffa022f560>] __hif_usb_tx+0x1c1/0x21b [ath9k_htc] [ 602.894005] [<ffffffffa022f73c>] hif_usb_tx_cb+0x12f/0x154 [ath9k_htc] [ 602.894005] [<ffffffffa00d2fbe>] usb_hcd_giveback_urb+0x91/0xc5 [usbcore] [ 602.894005] [<ffffffffa00f6c34>] ehci_urb_done+0x7a/0x8b [ehci_hcd] [ 602.894005] [<ffffffffa00f6f33>] qh_completions+0x2ee/0x376 [ehci_hcd] [ 602.894005] [<ffffffffa00f8ba5>] ehci_work+0x95/0x76e [ehci_hcd] [ 602.894005] [<ffffffffa00fa5ae>] ? ehci_irq+0x2f/0x1d4 [ehci_hcd] [ 602.894005] [<ffffffffa00fa725>] ehci_irq+0x1a6/0x1d4 [ehci_hcd] [ 602.894005] [<ffffffff810a6d18>] ? __rcu_process_callbacks+0x7a/0x2df [ 602.894005] [<ffffffff810a47a4>] ? handle_fasteoi_irq+0x22/0xd2 [ 602.894005] [<ffffffffa00d268d>] usb_hcd_irq+0x4a/0xa7 [usbcore] [ 602.894005] [<ffffffff810a2853>] handle_IRQ_event+0x77/0x14f [ 602.894005] [<ffffffff813285ce>] ? skb_release_data+0xc9/0xce [ 602.894005] [<ffffffff810a4814>] handle_fasteoi_irq+0x92/0xd2 [ 602.894005] [<ffffffff8100c4fb>] handle_irq+0x88/0x91 [ 602.894005] [<ffffffff8100baed>] do_IRQ+0x63/0xc9 [ 602.894005] [<ffffffff81354245>] ? ip_flush_pending_frames+0x4d/0x5c [ 602.894005] [<ffffffff813ba993>] ret_from_intr+0x0/0x16 [ 602.894005] <EOI> [<ffffffff811095fe>] ? __delete_object+0x5a/0xb1 [ 602.894005] [<ffffffff813ba5f5>] ? _raw_write_unlock_irqrestore+0x47/0x7e [ 602.894005] [<ffffffff813ba5fa>] ? _raw_write_unlock_irqrestore+0x4c/0x7e [ 602.894005] [<ffffffff811095fe>] __delete_object+0x5a/0xb1 [ 602.894005] [<ffffffff81109814>] delete_object_full+0x25/0x31 [ 602.894005] [<ffffffff813a60c0>] kmemleak_free+0x26/0x45 [ 602.894005] [<ffffffff810ff517>] kfree+0xaa/0x149 [ 602.894005] [<ffffffff81323fb7>] ? sock_def_write_space+0x84/0x89 [ 602.894005] [<ffffffff81354245>] ? ip_flush_pending_frames+0x4d/0x5c [ 602.894005] [<ffffffff813285ce>] skb_release_data+0xc9/0xce [ 602.894005] [<ffffffff813282a2>] __kfree_skb+0x1e/0x81 [ 602.894005] [<ffffffff813283b2>] kfree_skb+0x7e/0x86 [ 602.894005] [<ffffffff81354245>] ip_flush_pending_frames+0x4d/0x5c [ 602.894005] [<ffffffff81370c1f>] raw_sendmsg+0x653/0x709 [ 602.894005] [<ffffffff81379e31>] inet_sendmsg+0x54/0x5d [ 602.894005] [<ffffffff813207a2>] ? sock_recvmsg+0xc6/0xdf [ 602.894005] [<ffffffff813208c1>] sock_sendmsg+0xc0/0xd9 [ 602.894005] [<ffffffff810e13b4>] ? might_fault+0x68/0xb8 [ 602.894005] [<ffffffff810e13fd>] ? might_fault+0xb1/0xb8 [ 602.894005] [<ffffffff8132a1c3>] ? copy_from_user+0x2f/0x31 [ 602.894005] [<ffffffff8132a5b3>] ? verify_iovec+0x54/0x91 [ 602.894005] [<ffffffff81320d41>] sys_sendmsg+0x1da/0x241 [ 602.894005] [<ffffffff8103d327>] ? finish_task_switch+0x0/0xc9 [ 602.894005] [<ffffffff8103d327>] ? finish_task_switch+0x0/0xc9 [ 602.894005] [<ffffffff8107642e>] ? trace_hardirqs_on_caller+0x16/0x150 [ 602.894005] [<ffffffff813ba27d>] ? _raw_spin_unlock_irq+0x56/0x63 [ 602.894005] [<ffffffff8103d3cb>] ? finish_task_switch+0xa4/0xc9 [ 602.894005] [<ffffffff8103d327>] ? finish_task_switch+0x0/0xc9 [ 602.894005] [<ffffffff810357fe>] ? need_resched+0x23/0x2d [ 602.894005] [<ffffffff8107642e>] ? trace_hardirqs_on_caller+0x16/0x150 [ 602.894005] [<ffffffff813b9750>] ? trace_hardirqs_on_thunk+0x3a/0x3f [ 602.894005] [<ffffffff81009c02>] system_call_fastpath+0x16/0x1b [ 602.894005] ---[ end trace 91ba2d8dc7826839 ]--- [2] lockdep warning [ 169.363215] ====================================================== [ 169.365390] [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ] [ 169.366334] 2.6.34-rc3-wl #20 [ 169.366872] ------------------------------------------------------ [ 169.366872] khubd/78 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: [ 169.366872] (clock-AF_INET){++.?..}, at: [<ffffffff81323f51>] sock_def_write_space+0x1e/0x89 [ 169.366872] [ 169.366872] and this task is already holding: [ 169.366872] (&(&hif_dev->tx.tx_lock)->rlock){-.-...}, at: [<ffffffffa03715b0>] hif_usb_stop+0x24/0x53 [ath9k_htc] [ 169.366872] which would create a new lock dependency: [ 169.366872] (&(&hif_dev->tx.tx_lock)->rlock){-.-...} -> (clock-AF_INET){++.?..} [ 169.366872] [ 169.366872] but this new dependency connects a HARDIRQ-irq-safe lock: [ 169.366872] (&(&hif_dev->tx.tx_lock)->rlock){-.-...} [ 169.366872] ... which became HARDIRQ-irq-safe at: [ 169.366872] [<ffffffff810772d5>] __lock_acquire+0x2c6/0xd2b [ 169.366872] [<ffffffff8107866d>] lock_acquire+0xec/0x119 [ 169.366872] [<ffffffff813b99bb>] _raw_spin_lock+0x40/0x73 [ 169.366872] [<ffffffffa037163d>] hif_usb_tx_cb+0x5e/0x154 [ath9k_htc] [ 169.366872] [<ffffffffa00d2fbe>] usb_hcd_giveback_urb+0x91/0xc5 [usbcore] [ 169.366872] [<ffffffffa00f6c34>] ehci_urb_done+0x7a/0x8b [ehci_hcd] [ 169.366872] [<ffffffffa00f6f33>] qh_completions+0x2ee/0x376 [ehci_hcd] [ 169.366872] [<ffffffffa00f8ba5>] ehci_work+0x95/0x76e [ehci_hcd] [ 169.366872] [<ffffffffa00fa725>] ehci_irq+0x1a6/0x1d4 [ehci_hcd] [ 169.366872] [<ffffffffa00d268d>] usb_hcd_irq+0x4a/0xa7 [usbcore] [ 169.366872] [<ffffffff810a2853>] handle_IRQ_event+0x77/0x14f [ 169.366872] [<ffffffff810a4814>] handle_fasteoi_irq+0x92/0xd2 [ 169.366872] [<ffffffff8100c4fb>] handle_irq+0x88/0x91 [ 169.366872] [<ffffffff8100baed>] do_IRQ+0x63/0xc9 [ 169.366872] [<ffffffff813ba993>] ret_from_intr+0x0/0x16 [ 169.366872] [<ffffffff8130f6ee>] cpuidle_idle_call+0xa7/0x115 [ 169.366872] [<ffffffff81008c4f>] cpu_idle+0x68/0xc4 [ 169.366872] [<ffffffff813a41e0>] rest_init+0x104/0x10b [ 169.366872] [<ffffffff81899db3>] start_kernel+0x3f1/0x3fc [ 169.366872] [<ffffffff818992c8>] x86_64_start_reservations+0xb3/0xb7 [ 169.366872] [<ffffffff818993c4>] x86_64_start_kernel+0xf8/0x107 [ 169.366872] [ 169.366872] to a HARDIRQ-irq-unsafe lock: [ 169.366872] (clock-AF_INET){++.?..} [ 169.366872] ... which became HARDIRQ-irq-unsafe at: [ 169.366872] ... [<ffffffff81077349>] __lock_acquire+0x33a/0xd2b [ 169.366872] [<ffffffff8107866d>] lock_acquire+0xec/0x119 [ 169.366872] [<ffffffff813b9d07>] _raw_write_lock_bh+0x45/0x7a [ 169.366872] [<ffffffff8135cf14>] tcp_close+0x165/0x34d [ 169.366872] [<ffffffff8137aced>] inet_release+0x55/0x5c [ 169.366872] [<ffffffff81321350>] sock_release+0x1f/0x6e [ 169.366872] [<ffffffff813213c6>] sock_close+0x27/0x2b [ 169.366872] [<ffffffff8110dd45>] __fput+0x125/0x1ca [ 169.366872] [<ffffffff8110de04>] fput+0x1a/0x1c [ 169.366872] [<ffffffff8110adc9>] filp_close+0x68/0x72 [ 169.366872] [<ffffffff8110ae80>] sys_close+0xad/0xe7 [ 169.366872] [<ffffffff81009c02>] system_call_fastpath+0x16/0x1b (Trimmed at the "other info that might help us debug this" line in the interest of brevity... -- JWL) Signed-off-by: NMing Lei <tom.leiming@gmail.com> Acked-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ming Lei 提交于
In ath9k-htc register out path, ath9k-htc will pass skb->data into usb hcd and usb hcd will do dma mapping and unmapping to the buffer pointed by skb->data, so we should pass a cache-line aligned address. This patch replace __dev_alloc_skb with alloc_skb to make skb->data pointed to a cacheline aligned address simply since ath9k-htc does not skb_push on the skb and pass it to mac80211, also use kfree_skb to free the skb allocated by alloc_skb(we can use kfree_skb safely in hardirq context since skb->destructor is NULL always in the path). Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NMing Lei <tom.leiming@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ming Lei 提交于
In ath9k-htc register in path, ath9k-htc will pass skb->data into usb hcd and usb hcd will do dma mapping and unmapping to the buffer pointed by skb->data, so we should pass a cache-line aligned address. This patch replace __dev_alloc_skb with alloc_skb to make skb->data pointed to a cacheline aligned address simply since ath9k-htc does not skb_push on the skb and pass it to mac80211, also use kfree_skb to free the skb allocated by alloc_skb(we can use kfree_skb safely in hardirq context since skb->destructor is NULL always in the path). Signed-off-by: NMing Lei <tom.leiming@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ming Lei 提交于
In ath9k_hif_usb_alloc_rx_urbs, ath9k-htc will pass skb->data into usb hcd and usb hcd will do dma mapping and unmapping to the buffer pointed by skb->data, so we should pass a cache-line aligned address. This patch replace __dev_alloc_skb with alloc_skb to make skb->data pointed to a cacheline aligned address simply since ath9k-htc does not skb_push on the skb and pass it to mac80211, also use kfree_skb to free the skbs allocated by alloc_skb(we can use kfree_skb safely in hardirq context since skb->destructor is NULL always in the path). Signed-off-by: NMing Lei <tom.leiming@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Bruno Randolf 提交于
We get RXORN interrupts when all receive buffers are full. This is not necessarily a fatal situation. It can also happen when the bus is busy or the CPU is not fast enough to process all frames. Older chipsets apparently need a reset to come out of this situration, but on newer chips we can treat RXORN like RX, as going thru a full reset does more harm than good, there. The exact chip revisions which need a reset are unknown - this guess AR5K_SREV_AR5212 ("venice") is copied from the HAL. Inspired by openwrt 413-rxorn.patch: "treat rxorn like rx, reset after rxorn seems to do more harm than good" Signed-off-by: NBruno Randolf <br1@einfach.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Bruno Randolf 提交于
There was a confusion in the usage of the bits AR5K_STA_ID1_ACKCTS_6MB and AR5K_STA_ID1_BASE_RATE_11B. If they are set (1), we will get lower bitrates for ACK and CTS. Therefore ath5k_hw_set_ack_bitrate_high(ah, false) actually resulted in high bitrates, which i think is what we want anyways. Cleared the confusion and added some documentation. Signed-off-by: NBruno Randolf <br1@einfach.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 09 4月, 2010 10 次提交
-
-
由 John W. Linville 提交于
Resolution of a merge conflict upstream accidentally removed a hunk of "ath5k: IQ calibration for AR5211 is slightly different", so restore it. Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Bob Copeland 提交于
We check the bounds on pdadc once when correcting for negative curves but not when we later copy values from from the pdadc_tmp array, leading to a potential overrun. Although we shouldn't hit this case in practice, let's be consistent. Reported-by: NDan Carpenter <error27@gmail.com> Signed-off-by: NBob Copeland <me@bobcopeland.com> Acked-by: NBruno Randolf <br1@einfach.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Bob Copeland 提交于
As pointed out by Benoit Papillault, there is a potential race condition between the host and the hardware in reading the next link in the transmit descriptor list: cpu0 hw tx for buf completed raise tx_ok interrupt process buf buf->ds_link = 0 read buf->ds_link This change checks txdp before processing a descriptor (if there are any subsequent descriptors) to see if hardware moved on. We'll then process this descriptor on the next tasklet. Signed-off-by: NBob Copeland <me@bobcopeland.com> Acked-by: NBruno Randolf <br1@einfach.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Bob Copeland 提交于
Review spotted a couple of strange invocations to ieee80211_wake_queues that could potentially cause problems: - queues are awakened in the calibration tasklet before phy calibration, and then again after calibration - queues are awakened inside reset when we're trying to drain the ath5k transmit queues, and again after reset is completed (in callers to ath5k_reset_wake). In both cases the first wake is unnecessary, so remove it. Signed-off-by: NBob Copeland <me@bobcopeland.com> Acked-by: NBruno Randolf <br1@einfach.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Bob Copeland 提交于
These channels aren't selectable anyway, but our calculations for 2.5 mhz frequencies are incorrect. The value is supposed to be: (frequency - reference) * (10/25) i.e., divide by 2.5, but we were instead doing: (10 * frequency - reference) / 25. Additionally, the check for (frequency % 5 == 2) had an extra subtraction that wasn't in madwifi HAL. Signed-off-by: NBob Copeland <me@bobcopeland.com> Acked-by: NBruno Randolf <br1@einfach.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Pavel Roskin 提交于
Don't modify ah->iniModes, it's supposed to be constant. Instead, apply the fixup when the data is written to the registers. Change ath9k_hw_init_eeprom_fix() to only determine whether the fixup is needed. This allows similteneous support for AR9220 cards that need AR_AN_TOP2 fixup (such as Ubiquiti SR71-12) and those that don't need it (D-Link DWA-552 rev A2). Signed-off-by: NPavel Roskin <proski@gnu.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith 提交于
Messages that are generated by the HTC layer don't have any TX callback endpoints assigned to them. Consequently, the allocated SKBs are never freed. Fix this issue by handling this case in the HTC layer itself. Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith 提交于
hif_usb_regout_cb() frees the given URB, which is borked by design. Use an anchor to simplify URB management. Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith 提交于
The maximum number of packets in a single buffer in stream mode is 10. The driver currently uses 8 - which caused stack corruption, in the absence of any kind of OOB checking. Fixing this to the correct value of 10 fixes the module unload issue. Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Tested-by: NMing Lei <tom.leiming@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith 提交于
RX URBs are automatically freed when the reference count drops to zero - this currently doesn't happen when usb_kill_anchored_urbs() is called during unload. Fix this by dropping the reference count by one during initial submission. Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-