1. 14 4月, 2011 1 次提交
  2. 01 3月, 2011 1 次提交
  3. 24 2月, 2011 2 次提交
  4. 05 1月, 2011 1 次提交
  5. 23 12月, 2010 1 次提交
  6. 14 12月, 2010 1 次提交
  7. 09 12月, 2010 1 次提交
  8. 08 12月, 2010 2 次提交
    • S
      ath9k_htc: Fix panic on FW download failure · caa0a99a
      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>
      caa0a99a
    • S
      ath9k_htc: Cleanup device identification · 0b5ead91
      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>
      0b5ead91
  9. 03 12月, 2010 2 次提交
  10. 25 11月, 2010 2 次提交
  11. 17 11月, 2010 2 次提交
  12. 09 11月, 2010 2 次提交
  13. 28 10月, 2010 1 次提交
  14. 17 9月, 2010 1 次提交
  15. 15 9月, 2010 1 次提交
  16. 25 8月, 2010 1 次提交
  17. 14 8月, 2010 1 次提交
  18. 08 7月, 2010 1 次提交
  19. 24 6月, 2010 1 次提交
  20. 19 6月, 2010 1 次提交
  21. 05 6月, 2010 2 次提交
  22. 03 6月, 2010 1 次提交
  23. 25 5月, 2010 2 次提交
  24. 13 5月, 2010 2 次提交
  25. 27 4月, 2010 4 次提交
  26. 17 4月, 2010 1 次提交
  27. 15 4月, 2010 2 次提交
    • M
      ath9k-htc: fix lockdep warning and kernel warning after unplugging ar9271 usb device · f8e1d080
      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>
      f8e1d080
    • M
      ath9k-htc:respect usb buffer cacheline alignment in reg out path · 0fa35a58
      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>
      0fa35a58