1. 04 Apr, 2011 4 commits
  2. 31 Jan, 2011 6 commits
  3. 21 Jan, 2011 1 commit
    • Bruno Randolf's avatar
      cfg80211: Extend channel to frequency mapping for 802.11j · 59eb21a6
      Bruno Randolf authored
      
      
      Extend channel to frequency mapping for 802.11j Japan 4.9GHz band, according to
      IEEE802.11 section 17.3.8.3.2 and Annex J. Because there are now overlapping
      channel numbers in the 2GHz and 5GHz band we can't map from channel to
      frequency without knowing the band. This is no problem as in most contexts we
      know the band. In places where we don't know the band (and WEXT compatibility)
      we assume the 2GHz band for channels below 14.
      
      This patch does not implement all channel to frequency mappings defined in
      802.11, it's just an extension for 802.11j 20MHz channels. 5MHz and 10MHz
      channels as well as 802.11y channels have been omitted.
      
      The following drivers have been updated to reflect the API changes:
      iwl-3945, iwl-agn, iwmc3200wifi, libertas, mwl8k, rt2x00, wl1251, wl12xx.
      The drivers have been compile-tested only.
      Signed-off-by: default avatarBruno Randolf <br1@einfach.org>
      Signed-off-by: default avatarBrian Prodoehl <bprodoehl@gmail.com>
      Acked-by: default avatarLuciano Coelho <coelho@ti.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      59eb21a6
  4. 04 Jan, 2011 2 commits
  5. 20 Dec, 2010 1 commit
  6. 13 Dec, 2010 5 commits
  7. 30 Nov, 2010 1 commit
  8. 17 Nov, 2010 1 commit
  9. 15 Nov, 2010 3 commits
  10. 11 Oct, 2010 4 commits
  11. 05 Oct, 2010 2 commits
    • Helmut Schaa's avatar
      rt2x00: Fix oops caused by error path in rt2x00lib_start · 1f0280cb
      Helmut Schaa authored
      
      
      When rt2x00lib_enable_radio fails to enable the radio, rt2x00lib_start
      will call rt2x00queue_uninitialize to uninitialize the queues. Since,
      the queues are not initialized here but already in rt2x00lib_initialize
      we shouldn't uninitialize the queues here. Otherwise, a consecutive call
      to rt2x00lib_start will oops (see below) because it assumes the queues
      are already initialized.
      
      BUG: unable to handle kernel NULL pointer dereference at 00000010
      IP: [<f8d2d901>] :rt2800pci:rt2800pci_clear_entry+0x1/0x40
      *pde = 00000000
      Oops: 0000 [#1] SMP
      Modules linked in: ... rt2800pci ...
      
      Pid: 5995, comm: hostapd Not tainted (2.6.27.8 #1)
      EIP: 0060:[<f8d2d901>] EFLAGS: 00210246 CPU: 3
      EIP is at rt2800pci_clear_entry+0x1/0x40 [rt2800pci]
      EAX: 00000000 EBX: f698863c ECX: 00200296 EDX: f8d2dee0
      ESI: f6988600 EDI: f5b6f000 EBP: 00000000 ESP: f6d75e4c
       DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
      Process hostapd (pid: 5995, ti=f6d74000 task=f6ce2300 task.ti=f6d74000)
      Stack: f698863c fa00eaec 00000000 f5b6f000 00000000 f7b67000 f5b6e280 fa00c629
            f5b6f000 00000000 fa00ca3d f7b67480 00000001 fa177d4c 01b6e890 f7b67000
            00000000 f7b67000 00000001 00001003 00001002 c066c366 f7b67000 c0668ad0
      Call Trace:
       [<fa00eaec>] rt2x00queue_init_queues+0x5c/0x90 [rt2x00lib]
       [<fa00c629>] rt2x00lib_enable_radio+0x29/0xa0 [rt2x00lib]
       [<fa00ca3d>] rt2x00lib_start+0x5d/0xd0 [rt2x00lib]
       [<fa177d4c>] ieee80211_do_open+0x21c/0x510 [mac80211]
       [<c066c366>] dev_open+0x56/0xb0
       [<c0668ad0>] dev_set_rx_mode+0x20/0x40
       [<c066a67f>] dev_change_flags+0x7f/0x190
       [<c06b1495>] devinet_ioctl+0x515/0x690
       [<c0668d24>] __dev_get_by_name+0x74/0x90
       [<c065d3f0>] sock_ioctl+0xd0/0x240
       [<c065d320>] sock_ioctl+0x0/0x240
       [<c018179b>] vfs_ioctl+0x2b/0x90
       [<c0181a5b>] do_vfs_ioctl+0x25b/0x2a0
       [<c0181af6>] sys_ioctl+0x56/0x70
       [<c0103262>] syscall_call+0x7/0xb
       [<c0700000>] add_card+0xad0/0xba0
       =======================
      Code: 83 78 08 0e 74 14 8b 02 8b 48 04 85 c9 0f 99 c0 0f b6 c0 c3 8d b6
            00 00 00 00 8b 02 8b 40 04 85 c0 0f 99 c0 0f b6 c0 c3 66 90 53 <8b>
            48 10 8b 58 08 8b 40 04 83 78 08 0e 74 15 8b 11 83 c2 04 8b
      EIP: [<f8d2d901>] rt2800pci_clear_entry+0x1/0x40 [rt2800pci] SS:ESP 0068:f6d75e4c
      ---[ end trace cff9a5c094bb8837 ]---
      Reported-by: default avatarJoshua Smith <jesmith@kaon.com>
      Signed-off-by: default avatarHelmut Schaa <helmut.schaa@googlemail.com>
      Signed-off-by: default avatarIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      1f0280cb
    • Helmut Schaa's avatar
      rt2x00: rework tx status handling in rt2800pci · 96c3da7d
      Helmut Schaa authored
      
      
      This patch changes the way tx status reports are handled by rt2800pci.
      Previously rt2800pci would sometimes lose tx status reports as the
      TX_STA_FIFO register is a fifo of 16 entries that can overflow in case
      we don't read it often/fast enough. Since interrupts are disabled in the
      device during the execution of the interrupt thread it happend sometimes
      under high network and CPU load that processing took too long and a few
      tx status reports were dropped by the hw.
      
      To fix this issue the TX_STA_FIFO register is read directly in the
      interrupt handler and stored in a kfifo which is large enough to hold
      all status reports of all used tx queues.
      
      To process the status reports a new tasklet txstatus_tasklet is used.
      Using the already used interrupt thread is not possible since we don't
      want to disable the TX_FIFO_STATUS interrupt while processing them and
      it is not possible to schedule the interrupt thread multiple times for
      execution. A tasklet instead can be scheduled multiple times which
      allows to leave the TX_FIFO_STATUS interrupt enabled while a previously
      scheduled tasklet is still executing.
      
      In short: All other interrupts are handled in the interrupt thread as
      before. Only the TX_FIFO_STATUS interrupt is partly handled in the
      interrupt handler and finished in the according tasklet.
      
      One drawback of this patch is that it duplicates some code from
      rt2800lib. However, that can be cleaned up in the future once the
      rt2800usb and rt2800pci tx status handling converge more.
      
      Using this patch on a Ralink RT3052 embedded board gives me a reliable
      wireless connection even under high CPU and network load. I've
      transferred several gigabytes without any queue lockups.
      Signed-off-by: default avatarHelmut Schaa <helmut.schaa@googlemail.com>
      Signed-off-by: default avatarIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      96c3da7d
  12. 31 Aug, 2010 1 commit
    • Ivo van Doorn's avatar
      rt2x00: Split watchdog check into a DMA and STATUS timeout · 652a9dd2
      Ivo van Doorn authored
      
      
      The watchdog for rt2800usb triggers frequently causing all URB's
      to be canceled often enough to interrupt the normal TX flow.
      More research indicated that not the URB upload to the USB host
      were hanging, but instead the TX status reports.
      
      To correctly detect what is going on, we introduce Q_INDEX_DMA_DONE
      which is an index counter between Q_INDEX_DONE and Q_INDEX and indicates
      if the frame has been transfered to the device.
      
      This also requires the rt2x00queue timeout functions to be updated
      to differentiate between a DMA timeout (time between Q_INDEX and
      Q_INDEX_DMA_DONE timeout) and a STATUS timeout (time between
      Q_INDEX_DMA_DONE and Q_INDEX_DONE timeout)
      
      All Q_INDEX_DMA_DONE code was taken from the RFC from
      Helmut Schaa <helmut.schaa@googlemail.com> for the implementation
      for watchdog for rt2800pci.
      Signed-off-by: default avatarIvo van Doorn <IvDoorn@gmail.com>
      Acked-by: default avatarGertjan van Wingerde <gwingerde@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      652a9dd2
  13. 25 Aug, 2010 1 commit
  14. 16 Aug, 2010 3 commits
  15. 16 Jul, 2010 1 commit
    • Stephen Boyd's avatar
      rt2x00: Fix lockdep warning in rt2x00lib_probe_dev() · 9acd56d3
      Stephen Boyd authored
      
      
      The rt2x00dev->intf_work workqueue is never initialized when a driver is
      probed for a non-existent device (in this case rt2500usb). On such a
      path we call rt2x00lib_remove_dev() to free any resources initialized
      during the probe before we use INIT_WORK to initialize the workqueue.
      This causes lockdep to get confused since the lock used in the workqueue
      hasn't been initialized yet but is now being acquired during
      cancel_work_sync() called by rt2x00lib_remove_dev().
      
      Fix this by initializing the workqueue first before we attempt to probe
      the device. This should make lockdep happy and avoid breaking any
      assumptions about how the library cleans up after a probe fails.
      
      phy0 -> rt2x00lib_probe_dev: Error - Failed to allocate device.
      INFO: trying to register non-static key.
      the code is fine but needs lockdep annotation.
      turning off the locking correctness validator.
      Pid: 2027, comm: modprobe Not tainted 2.6.35-rc5+ #60
      Call Trace:
       [<ffffffff8105fe59>] register_lock_class+0x152/0x31f
       [<ffffffff81344a00>] ? usb_control_msg+0xd5/0x111
       [<ffffffff81061bde>] __lock_acquire+0xce/0xcf4
       [<ffffffff8105f6fd>] ? trace_hardirqs_off+0xd/0xf
       [<ffffffff81492aef>] ?  _raw_spin_unlock_irqrestore+0x33/0x41
       [<ffffffff810628d5>] lock_acquire+0xd1/0xf7
       [<ffffffff8104f037>] ? __cancel_work_timer+0x99/0x17e
       [<ffffffff8104f06e>] __cancel_work_timer+0xd0/0x17e
       [<ffffffff8104f037>] ? __cancel_work_timer+0x99/0x17e
       [<ffffffff8104f136>] cancel_work_sync+0xb/0xd
       [<ffffffffa0096675>] rt2x00lib_remove_dev+0x25/0xb0 [rt2x00lib]
       [<ffffffffa0096bf7>] rt2x00lib_probe_dev+0x380/0x3ed [rt2x00lib]
       [<ffffffff811d78a7>] ? __raw_spin_lock_init+0x31/0x52
       [<ffffffffa00bbd2c>] ? T.676+0xe/0x10 [rt2x00usb]
       [<ffffffffa00bbe4f>] rt2x00usb_probe+0x121/0x15e [rt2x00usb]
       [<ffffffff813468bd>] usb_probe_interface+0x151/0x19e
       [<ffffffff812ea08e>] driver_probe_device+0xa7/0x136
       [<ffffffff812ea167>] __driver_attach+0x4a/0x66
       [<ffffffff812ea11d>] ? __driver_attach+0x0/0x66
       [<ffffffff812e96ca>] bus_for_each_dev+0x54/0x89
       [<ffffffff812e9efd>] driver_attach+0x19/0x1b
       [<ffffffff812e9b64>] bus_add_driver+0xb4/0x204
       [<ffffffff812ea41b>] driver_register+0x98/0x109
       [<ffffffff813465dd>] usb_register_driver+0xb2/0x173
       [<ffffffffa00ca000>] ? rt2500usb_init+0x0/0x20 [rt2500usb]
       [<ffffffffa00ca01e>] rt2500usb_init+0x1e/0x20 [rt2500usb]
       [<ffffffff81000203>] do_one_initcall+0x6d/0x17a
       [<ffffffff8106cae8>] sys_init_module+0x9c/0x1e0
       [<ffffffff8100296b>] system_call_fastpath+0x16/0x1b
      Signed-off-by: default avatarStephen Boyd <bebarino@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      9acd56d3
  16. 12 Jul, 2010 4 commits