1. 16 Apr, 2010 21 commits
  2. 14 Apr, 2010 9 commits
    • Xose Vazquez Perez's avatar
      wireless: rt2x00: rt2800usb: identify Sitecom devices · a5e944f1
      Xose Vazquez Perez authored
      A very useful information was provided by Sitecom R&D guys:
      
      Please find the information regarding our latest Ralink adapters below;
      
      WL-302    -    VID: 0x0DF6,    PID: 0x002D    -    Ralink RT2771
      WL-315    -    VID: 0x0DF6,    PID: 0x0039    -    Ralink RT2770
      WL-319    -    VID: 0x182D,    PID: 0x0037    -    Ralink RT2860
      WL-321    -    VID: 0x0DF6,    PID: 0x003B    -    Ralink RT2770
      WL-324    -    VID: 0x0DF6,    PID: 0x003D    -    Ralink RT2870
      WL-329    -    VID: 0x0DF6,    PID: 0x0041    -    Ralink RT3572
      WL-343    -    VID: 0x0DF6,    PID: 0x003E    -    Ralink RT3070
      WL-344    -    VID: 0x0DF6,    PID: 0x0040    -    Ralink RT3071
      WL-345    -    VID: 0x0DF6,    PID: 0x0042    -    Ralink RT3072
      WL-608    -    VID: 0x0DF6,    PID: 0x003F    -    Ralink RT2070
      
      Note:
      PID: 0x003C, 0x004A, and 0x004D:   --these products do not exist; devices were never produced/shipped--
      
      The WL-349v4 USB dongle (0x0df6,0x0050) will be shipped soon (it isn't available yet), and uses a Ralink RT3370 chipset.
      Signed-off-by: default avatarXose Vazquez Perez <xose.vazquez@gmail.com>
      Acked-by: default avatarGertjan van Wingerde <gwingerde@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      a5e944f1
    • Christian Lamparter's avatar
      ar9170usb: add a couple more USB IDs · 94d0bbe8
      Christian Lamparter authored
      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: default avatarChristian Lamparter <chunkeey@googlemail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      94d0bbe8
    • Grazvydas Ignotas's avatar
      wl1251: don't require NVS data when EEPROM is used · afa5ec27
      Grazvydas Ignotas authored
      If EEPROM is used, NVS data is now loaded but ignored.
      Stop loading it to avoid need of dummy NVS file for modules with EEPROM.
      Signed-off-by: default avatarGrazvydas Ignotas <notasas@gmail.com>
      Acked-by: default avatarKalle Valo <kvalo@adurom.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      afa5ec27
    • Ming Lei's avatar
      ath9k-htc: fix lockdep warning and kernel warning after unplugging ar9271 usb device · f8e1d080
      Ming Lei authored
      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: default avatarMing Lei <tom.leiming@gmail.com>
      Acked-by: default avatarSujith <Sujith.Manoharan@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      f8e1d080
    • Ming Lei's avatar
      ath9k-htc:respect usb buffer cacheline alignment in reg out path · 0fa35a58
      Ming Lei authored
      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: default avatarSujith <Sujith.Manoharan@atheros.com>
      Signed-off-by: default avatarMing Lei <tom.leiming@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      0fa35a58
    • Ming Lei's avatar
      ath9k-htc:respect usb buffer cacheline alignment in reg in path · e6c6d33c
      Ming Lei authored
      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: default avatarMing Lei <tom.leiming@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      e6c6d33c
    • Ming Lei's avatar
      ath9k-htc:respect usb buffer cacheline alignment in ath9k_hif_usb_alloc_rx_urbs · f28a7b30
      Ming Lei authored
      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: default avatarMing Lei <tom.leiming@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      f28a7b30
    • Bruno Randolf's avatar
      ath5k: treat RXORN as non-fatal · 87d77c4e
      Bruno Randolf authored
      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: default avatarBruno Randolf <br1@einfach.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      87d77c4e
    • Bruno Randolf's avatar
      ath5k: Use high bitrates for ACK/CTS · 0edc9a67
      Bruno Randolf authored
      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: default avatarBruno Randolf <br1@einfach.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      0edc9a67
  3. 12 Apr, 2010 10 commits