1. 20 Sep, 2010 1 commit
  2. 17 Sep, 2010 1 commit
    • Wey-Yi Guy's avatar
      iwlwifi: do not perferm force reset while doing scan · 7acc7c68
      Wey-Yi Guy authored
      When uCode error condition detected, driver try to perform either
      rf reset or firmware reload in order bring device back to
      working condition.
      If rf reset is required and scan is in process, there is no need
      to issue rf reset since scan already reset the rf.
      If firmware reload is required and scan is in process, skip the
      reload request. There is a possibility firmware reload during
      scan cause problem.
      [  485.804046] WARNING: at net/mac80211/main.c:310 ieee80211_restart_hw+0x28/0x62()
      [  485.804049] Hardware name: Latitude E6400
      [  485.804052] ieee80211_restart_hw called with hardware scan in progress
      [  485.804054] Modules linked in: iwlagn iwlcore bnep sco rfcomm l2cap crc16 bluetooth [last unloaded: iwlcore]
      [  485.804069] Pid: 812, comm: kworker/u:3 Tainted: G        W   2.6.36-rc3-wl+ #74
      [  485.804072] Call Trace:
      [  485.804079]  [<c103019a>] warn_slowpath_common+0x60/0x75
      [  485.804084]  [<c1030213>] warn_slowpath_fmt+0x26/0x2a
      [  485.804089]  [<c145da67>] ieee80211_restart_hw+0x28/0x62
      [  485.804102]  [<f8b35dc6>] iwl_bg_restart+0x113/0x150 [iwlagn]
      [  485.804108]  [<c10415d5>] process_one_work+0x181/0x25c
      [  485.804119]  [<f8b35cb3>] ? iwl_bg_restart+0x0/0x150 [iwlagn]
      [  485.804124]  [<c104190a>] worker_thread+0xf9/0x1f2
      [  485.804128]  [<c1041811>] ? worker_thread+0x0/0x1f2
      [  485.804133]  [<c10451b0>] kthread+0x64/0x69
      [  485.804137]  [<c104514c>] ? kthread+0x0/0x69
      [  485.804141]  [<c1002df6>] kernel_thread_helper+0x6/0x10
      [  485.804145] ---[ end trace 3d4ebdc02d524bbb ]---
      [  485.804148] WG> 1
      [  485.804153] Pid: 812, comm: kworker/u:3 Tainted: G        W   2.6.36-rc3-wl+ #74
      [  485.804156] Call Trace:
      [  485.804161]  [<c145da9b>] ? ieee80211_restart_hw+0x5c/0x62
      [  485.804172]  [<f8b35dcb>] iwl_bg_restart+0x118/0x150 [iwlagn]
      [  485.804177]  [<c10415d5>] process_one_work+0x181/0x25c
      [  485.804188]  [<f8b35cb3>] ? iwl_bg_restart+0x0/0x150 [iwlagn]
      [  485.804192]  [<c104190a>] worker_thread+0xf9/0x1f2
      [  485.804197]  [<c1041811>] ? worker_thread+0x0/0x1f2
      [  485.804201]  [<c10451b0>] kthread+0x64/0x69
      [  485.804205]  [<c104514c>] ? kthread+0x0/0x69
      [  485.804209]  [<c1002df6>] kernel_thread_helper+0x6/0x10
      Signed-off-by: default avatarWey-Yi Guy <wey-yi.w.guy@intel.com>
  3. 31 Aug, 2010 3 commits
    • Luis R. Rodriguez's avatar
      ath9k_hw: fix parsing of HT40 5 GHz CTLs · 90487974
      Luis R. Rodriguez authored
      The 5 GHz CTL indexes were not being read for all hardware
      devices due to the masking out through the CTL_MODE_M mask
      being one bit too short. Without this the calibrated regulatory
      maximum values were not being picked up when devices operate
      on 5 GHz in HT40 mode. The final output power used for Atheros
      devices is the minimum between the calibrated CTL values and
      what CRDA provides.
      Cc: stable@kernel.org [2.6.27+]
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Luis R. Rodriguez's avatar
      ath9k_hw: Fix EEPROM uncompress block reading on AR9003 · 803288e6
      Luis R. Rodriguez authored
      The EEPROM is compressed on AR9003, upon decompression
      the wrong upper limit was being used for the block which
      prevented the 5 GHz CTL indexes from being used, which are
      stored towards the end of the EEPROM block. This fix allows
      the actual intended regulatory limits to be used on AR9003
      Cc: stable@kernel.org [2.6.36+]
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • John W. Linville's avatar
      wireless: register wiphy rfkill w/o holding cfg80211_mutex · c3d34d5d
      John W. Linville authored
      Otherwise lockdep complains...
      [ INFO: possible circular locking dependency detected ]
      2.6.36-rc2-git4 #12
      kworker/0:3/3630 is trying to acquire lock:
       (rtnl_mutex){+.+.+.}, at: [<ffffffff813396c7>] rtnl_lock+0x12/0x14
      but task is already holding lock:
       (rfkill_global_mutex){+.+.+.}, at: [<ffffffffa014b129>]
      rfkill_switch_all+0x24/0x49 [rfkill]
      which lock already depends on the new lock.
      the existing dependency chain (in reverse order) is:
      -> #2 (rfkill_global_mutex){+.+.+.}:
             [<ffffffff81079ad7>] lock_acquire+0x120/0x15b
             [<ffffffff813ae869>] __mutex_lock_common+0x54/0x52e
             [<ffffffff813aede9>] mutex_lock_nested+0x34/0x39
             [<ffffffffa014b4ab>] rfkill_register+0x2b/0x29c [rfkill]
             [<ffffffffa0185ba0>] wiphy_register+0x1ae/0x270 [cfg80211]
             [<ffffffffa0206f01>] ieee80211_register_hw+0x1b4/0x3cf [mac80211]
             [<ffffffffa0292e98>] iwl_ucode_callback+0x9e9/0xae3 [iwlagn]
             [<ffffffff812d3e9d>] request_firmware_work_func+0x54/0x6f
             [<ffffffff81065d15>] kthread+0x8c/0x94
             [<ffffffff8100ac24>] kernel_thread_helper+0x4/0x10
      -> #1 (cfg80211_mutex){+.+.+.}:
             [<ffffffff81079ad7>] lock_acquire+0x120/0x15b
             [<ffffffff813ae869>] __mutex_lock_common+0x54/0x52e
             [<ffffffff813aede9>] mutex_lock_nested+0x34/0x39
             [<ffffffffa018605e>] cfg80211_get_dev_from_ifindex+0x1b/0x7c [cfg80211]
             [<ffffffffa0189f36>] cfg80211_wext_giwscan+0x58/0x990 [cfg80211]
             [<ffffffff8139a3ce>] ioctl_standard_iw_point+0x1a8/0x272
             [<ffffffff8139a529>] ioctl_standard_call+0x91/0xa7
             [<ffffffff8139a687>] T.723+0xbd/0x12c
             [<ffffffff8139a727>] wext_handle_ioctl+0x31/0x6d
             [<ffffffff8133014e>] dev_ioctl+0x63d/0x67a
             [<ffffffff8131afd9>] sock_ioctl+0x48/0x21d
             [<ffffffff81102abd>] do_vfs_ioctl+0x4ba/0x509
             [<ffffffff81102b5d>] sys_ioctl+0x51/0x74
             [<ffffffff81009e02>] system_call_fastpath+0x16/0x1b
      -> #0 (rtnl_mutex){+.+.+.}:
             [<ffffffff810796b0>] __lock_acquire+0xa93/0xd9a
             [<ffffffff81079ad7>] lock_acquire+0x120/0x15b
             [<ffffffff813ae869>] __mutex_lock_common+0x54/0x52e
             [<ffffffff813aede9>] mutex_lock_nested+0x34/0x39
             [<ffffffff813396c7>] rtnl_lock+0x12/0x14
             [<ffffffffa0185cb5>] cfg80211_rfkill_set_block+0x1a/0x7b [cfg80211]
             [<ffffffffa014aed0>] rfkill_set_block+0x80/0xd5 [rfkill]
             [<ffffffffa014b07e>] __rfkill_switch_all+0x3f/0x6f [rfkill]
             [<ffffffffa014b13d>] rfkill_switch_all+0x38/0x49 [rfkill]
             [<ffffffffa014b821>] rfkill_op_handler+0x105/0x136 [rfkill]
             [<ffffffff81060708>] process_one_work+0x248/0x403
             [<ffffffff81062620>] worker_thread+0x139/0x214
             [<ffffffff81065d15>] kthread+0x8c/0x94
             [<ffffffff8100ac24>] kernel_thread_helper+0x4/0x10
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      Acked-by: default avatarJohannes Berg <johannes@sipsolutions.net>
  4. 30 Aug, 2010 5 commits
  5. 27 Aug, 2010 1 commit
  6. 18 Aug, 2010 2 commits
  7. 17 Aug, 2010 2 commits
    • Johannes Berg's avatar
      iwlwifi: fix 3945 filter flags · 8b8ab9d5
      Johannes Berg authored
      Applying the filter flags directly as done since
      commit 3474ad63
      Author: Johannes Berg <johannes.berg@intel.com>
      Date:   Thu Apr 29 04:43:05 2010 -0700
          iwlwifi: apply filter flags directly
      broke 3945 under some unknown circumstances, as
      reported by Alex.
      Since I want to keep the direct application of
      filter flags on iwlagn, duplicate the code into
      both 3945 and agn and remove committing the
      RXON that broke things from the 3945 version.
      Cc: stable@kernel.org [2.6.35]
      Reported-by: default avatarAlex Romosan <romosan@sycorax.lbl.gov>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • John W. Linville's avatar
      ipw2100: don't sync status queue entries · c206a04f
      John W. Linville authored
      These are allocated with pci_alloc_consistent, so calling
      pci_dma_sync_single_for_cpu is incorrect usage of the API.  Remove this
      misuse and consequently avoid the following backtrace:
      WARNING: at lib/dma-debug.c:902 check_sync+0xce/0x43a()
      Hardware name: 2373HU6
      ipw2100 0000:02:02.0: DMA-API: device driver tries to sync DMA memory it has not allocated [device address=0x0000000034e88008] [size=8 bytes]
      Modules linked in: microcode ipw2100(+) snd_seq_device ppdev libipw nsc_ircc snd_pcm lib80211 video output irda parport_pc cfg80211 parport thinkpad_acpi e1000 iTCO_wdt crc_ccitt snd_timer iTCO_vendor_support snd i2c_i801 pcspkr rfkill soundcore joydev snd_page_alloc yenta_socket radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan]
      Pid: 0, comm: swapper Tainted: G        W   2.6.35-wl+ #8
      Call Trace:
       [<c043aa42>] warn_slowpath_common+0x6a/0x7f
       [<c05d252a>] ? check_sync+0xce/0x43a
       [<c043aaca>] warn_slowpath_fmt+0x2b/0x2f
       [<c05d252a>] check_sync+0xce/0x43a
       [<c046189a>] ? print_lock_contention_bug+0x11/0xb2
       [<c05d2b6f>] debug_dma_sync_single_for_cpu+0x47/0x49
       [<c06cbd3c>] ? ehci_irq+0x31/0x331
       [<f82a224a>] ? ipw2100_irq_tasklet+0x24/0x5e9 [ipw2100]
       [<f82a224a>] ? ipw2100_irq_tasklet+0x24/0x5e9 [ipw2100]
       [<f82a221d>] pci_dma_sync_single_for_cpu.clone.1+0x42/0x4b [ipw2100]
       [<f82a23a2>] ipw2100_irq_tasklet+0x17c/0x5e9 [ipw2100]
       [<c043fd87>] tasklet_action+0x78/0xcb
       [<c0440293>] __do_softirq+0xc4/0x183
       [<c044038d>] do_softirq+0x3b/0x5f
       [<c04404d0>] irq_exit+0x3a/0x6d
       [<c0404423>] do_IRQ+0x8b/0x9f
       [<c04038b5>] common_interrupt+0x35/0x3c
       [<c062ecfa>] ? acpi_idle_enter_simple+0xfe/0x13c
       [<c045007b>] ? exit_itimers+0x2d/0x73
       [<c062ecfc>] ? acpi_idle_enter_simple+0x100/0x13c
       [<c070bf10>] cpuidle_idle_call+0x78/0xdc
       [<c040251c>] cpu_idle+0x9b/0xb7
       [<c07b1dd2>] rest_init+0xa6/0xab
       [<c0a4b96d>] start_kernel+0x389/0x38e
       [<c0a4b0c9>] i386_start_kernel+0xc9/0xd0
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  8. 14 Aug, 2010 2 commits
    • Wey-Yi Guy's avatar
      iwlwifi: use long monitor timer to avoid un-necessary reload · 3198c68c
      Wey-Yi Guy authored
      For 5000 and 6000g2b series of devices, use long monitor timer to check
      stuck tx queues.
      .6000g2b series device, it is WiFi/BT combo device, there are some cases,
      tx queues are not move for a period of time because the WiFi/BT coex.
      .5000 series device, it is being reported firmware got reload more
      often than necessary, so extend the timer to avoid un-necessary reload.
      Signed-off-by: default avatarWey-Yi Guy <wey-yi.w.guy@intel.com>
    • Wey-Yi Guy's avatar
      iwlwifi: long monitor timer · ce60659a
      Wey-Yi Guy authored
      Change the name for monitor timer, also adding define for long monitor
      timer; long monitor timer can be used for the type of devices require longer
      time to determine the uCode is stuck on tx and needed reload.
      Signed-off-by: default avatarWey-Yi Guy <wey-yi.w.guy@intel.com>
  9. 13 Aug, 2010 4 commits
  10. 11 Aug, 2010 2 commits
    • Rajkumar Manoharan's avatar
      ath9k_htc: fix panic on packet injection using airbase-ng tool. · da93f106
      Rajkumar Manoharan authored
      This should fix the oops which occurs during the packet injection
      on monitor interface.
      EIP is at ath9k_htc_tx_start+0x69/0x220 [ath9k_htc]
       [<f84dc8ea>] ? invoke_tx_handlers+0xa5a/0xee0 [mac80211]
       [<f82c84f4>] ? ath9k_htc_tx+0x44/0xe0 [ath9k_htc]
       [<f84db7b8>] ? __ieee80211_tx+0xf8/0x190 [mac80211]
       [<f84dce0d>] ? ieee80211_tx+0x9d/0x1a0 [mac80211]
       [<f84dcfac>] ? ieee80211_xmit+0x9c/0x1c0 [mac80211]
       [<f84dd1b5>] ? ieee80211_monitor_start_xmit+0x85/0xb0 [mac80211]
       [<c04c30cd>] ? dev_hard_start_xmit+0x1ad/0x210
       [<c04b97c2>] ? __alloc_skb+0x52/0x130
       [<c04d7cd5>] ? sch_direct_xmit+0x105/0x170
       [<c04c5e9f>] ? dev_queue_xmit+0x37f/0x4b0
       [<c0567e1e>] ? packet_snd+0x21e/0x250
       [<c05684a2>] ? packet_sendmsg+0x32/0x40
       [<c04b4c63>] ? sock_aio_write+0x113/0x130
       [<c0207934>] ? do_sync_write+0xc4/0x100
       [<c0167740>] ? autoremove_wake_function+0x0/0x50
       [<c02f4414>] ? security_file_permission+0x14/0x20
       [<c0207ad4>] ? rw_verify_area+0x64/0xe0
       [<c01e6458>] ? handle_mm_fault+0x338/0x390
       [<c0207cd5>] ? vfs_write+0x185/0x1a0
       [<c058db20>] ? do_page_fault+0x160/0x3a0
       [<c0208512>] ? sys_write+0x42/0x70
       [<c01033ec>] ? syscall_call+0x7/0xb
      Signed-off-by: default avatarRajkumar Manoharan <rmanoharan@atheros.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • John W. Linville's avatar
      ipw2100: register pm_qos request before registering pci driver · 2f81b471
      John W. Linville authored
      It is necessary to call pm_qos_add_request prior to calling
      pm_qos_update_request.  It was revealed that ipw2100 has been
      doing this wrong since "pm_qos: Get rid of the allocation in
      pm_qos_add_request()" (commit 82f68251
      added a WARN that results in the following backtrace:
      WARNING: at kernel/pm_qos_params.c:264 pm_qos_update_request+0x5e/0x70()
      pm_qos_update_request() called for unknown object
      Call Trace:
      [<c1024088>] ? warn_slowpath_common+0x78/0xb0
      [<c1041c9e>] ? pm_qos_update_request+0x5e/0x70
      [<c1041c9e>] ? pm_qos_update_request+0x5e/0x70
      [<c1024153>] ? warn_slowpath_fmt+0x33/0x40
      [<c1041c9e>] ? pm_qos_update_request+0x5e/0x70
      [<f89fe15f>] ? ipw2100_up+0x3f/0xf10 [ipw2100]
      [<c11961c9>] ? vsnprintf+0xc9/0x530
      [<f89ff36c>] ? ipw2100_net_init+0x2c/0x1c0 [ipw2100]
      [<c12f542d>] ? register_netdevice+0x7d/0x3c0
      [<f89f9b00>] ? ipw2100_irq_tasklet+0x910/0x9a0 [ipw2100]
      [<c12f579f>] ? register_netdev+0x2f/0x40
      [<f89fd471>] ? ipw2100_pci_init_one+0xd21/0x1060 [ipw2100]
      [<c11a5ebb>] ? local_pci_probe+0xb/0x10
      [<c11a6d49>] ? pci_device_probe+0x69/0x90
      [<c1224704>] ? driver_probe_device+0x74/0x180
      [<c10dd15a>] ? sysfs_create_dir+0x6a/0xb0
      [<c1224889>] ? __driver_attach+0x79/0x80
      [<c1224810>] ? __driver_attach+0x0/0x80
      [<c1223fa2>] ? bus_for_each_dev+0x52/0x80
      [<c1224586>] ? driver_attach+0x16/0x20
      [<c1224810>] ? __driver_attach+0x0/0x80
      [<c122395f>] ? bus_add_driver+0x17f/0x250
      [<c11a5ec0>] ? pci_device_shutdown+0x0/0x20
      [<c11a6c80>] ? pci_device_remove+0x0/0x40
      [<c1224b13>] ? driver_register+0x63/0x120
      [<c11a6f96>] ? __pci_register_driver+0x36/0xa0
      [<f84f9048>] ? ipw2100_init+0x48/0x67 [ipw2100]
      [<c1001122>] ? do_one_initcall+0x32/0x170
      [<c1087078>] ? __vunmap+0xb8/0xf0
      [<f84f9000>] ? ipw2100_init+0x0/0x67 [ipw2100]
      [<c10510c1>] ? sys_init_module+0x161/0x1000
      [<c108f847>] ? sys_close+0x67/0xe0
      [<c13647c1>] ? syscall_call+0x7/0xb
      This patch moves pm_qos_add_request prior to pci_register_driver in
      ipw2100 in order to avoid this problem.
      Reported-by: default avatarChristoph Fritz <chf.fritz@googlemail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  11. 10 Aug, 2010 5 commits
  12. 09 Aug, 2010 4 commits
    • Johannes Berg's avatar
      iwlagn: fix rts cts protection · 94597ab2
      Johannes Berg authored
      Currently the driver will try to protect all frames,
      which leads to a lot of odd things like sending an
      RTS with a zeroed RA before multicast frames, which
      is clearly bogus.
      In order to fix all of this, we need to take a step
      back and see what we need to achieve:
       * we need RTS/CTS protection if requested by
         the AP for the BSS, mac80211 tells us this
       * in that case, CTS-to-self should only be
         enabled when mac80211 tells us
       * additionally, as a hardware workaround, on
         some devices we have to protect aggregated
         frames with RTS
      To achieve the first two items, set up the RXON
      accordingly and set the protection required flag
      in the transmit command when mac80211 requests
      protection for the frame.
      To achieve the last item, set the rate-control
      RTS-requested flag for all stations that we have
      aggregation sessions with, and set the protection
      required flag when sending aggregated frames (on
      those devices where this is required).
      Since otherwise bugs can occur, do not allow the
      user to override the RTS-for-aggregation setting
      from sysfs any more.
      Finally, also clean up the way all these flags get
      set in the driver and move everything into the
      device-specific functions.
      Cc: stable@kernel.org [2.6.35]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Johannes Berg's avatar
      cfg80211: fix locking in action frame TX · fe100acd
      Johannes Berg authored
      Accesses to "wdev->current_bss" must be
      locked with the wdev lock, which action
      frame transmission is missing.
      Cc: stable@kernel.org [2.6.33+]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • John W. Linville's avatar
      libertas: fix build break by including linux/sched.h · a9fda88b
      John W. Linville authored
        CC [M]  drivers/net/wireless/libertas/cfg.o
      /home/greearb/git/wireless-testing/drivers/net/wireless/libertas/cfg.c: In function ‘lbs_scan_worker’:
      /home/greearb/git/wireless-testing/drivers/net/wireless/libertas/cfg.c:722: error: ‘TASK_NORMAL’ undeclared (first use in this function)
      /home/greearb/git/wireless-testing/drivers/net/wireless/libertas/cfg.c:722: error: (Each undeclared identifier is reported only once
      /home/greearb/git/wireless-testing/drivers/net/wireless/libertas/cfg.c:722: error: for each function it appears in.)
      /home/greearb/git/wireless-testing/drivers/net/wireless/libertas/cfg.c: In function ‘lbs_cfg_connect’:
      /home/greearb/git/wireless-testing/drivers/net/wireless/libertas/cfg.c:1267: error: ‘TASK_INTERRUPTIBLE’ undeclared (first use in this function)
      /home/greearb/git/wireless-testing/drivers/net/wireless/libertas/cfg.c:1267: error: implicit declaration of function ‘signal_pending’
      /home/greearb/git/wireless-testing/drivers/net/wireless/libertas/cfg.c:1267: error: implicit declaration of function ‘schedule_timeout’
      Reported-by: default avatarBen Greear <greearb@candelatech.com>
      Reported-by: default avatarRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • John W. Linville's avatar
      Revert "p54pci: Add PCI ID for SMC2802W" · 2f2f8f2a
      John W. Linville authored
      This reverts commit 5f7aebd8
      Apparently, that PCI ID data was incorrectly taken from the subsystem
      information.  The actual ID matches another already known ID.
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  13. 08 Aug, 2010 8 commits