1. 03 7月, 2010 1 次提交
  2. 26 6月, 2010 1 次提交
  3. 22 6月, 2010 3 次提交
  4. 15 6月, 2010 3 次提交
  5. 06 6月, 2010 8 次提交
    • J
      iwlwifi: generic scan TX antenna forcing · 0e1654fa
      Johannes Berg 提交于
      In "iwlwifi: make scan antenna forcing more generic"
      I introduced generic scan RX antenna forcing, which
      here I rename to make it more evident. Also add scan
      TX antenna forcing, since I will need that as well.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      0e1654fa
    • J
      iwlwifi: reduce memory allocation · ff0d91c3
      Johannes Berg 提交于
      Currently, the driver allocates up to 19 skb pointers
      for each TFD, of which we have 256 per queue. This
      means that for each TX queue, we allocate 19k/38k
      (an order 4 or 5 allocation on 32/64 bit respectively)
      just for each queue's "txb" array, which contains only
      the SKB pointers.
      
      However, due to the way we use these pointers only the
      first one can ever be assigned. When the driver was
      initially written, the idea was that it could be
      passed multiple SKBs for each TFD and attach all
      those to implement gather DMA. However, due to
      constraints in the userspace API and lack of TCP/IP
      level checksumming in the device, this is in fact not
      possible. And even if it were, the SKBs would be
      chained, and we wouldn't need to keep pointers to
      each anyway.
      
      Change this to only keep track of one SKB per TFD,
      and thereby reduce memory consumption to just one
      pointer per TFD, which is an order 0 allocation per
      transmit queue.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      ff0d91c3
    • J
      iwlagn: fix bug in txq freeing · 6f80240e
      Johannes Berg 提交于
      The iwl_hw_txq_free_tfd() function can be
      called from contexts with IRQs disabled,
      so it must not call dev_kfree_skb() but
      rather dev_kfree_skb_any() instead.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      6f80240e
    • W
      iwlwifi: support channel switch offload in driver · 79d07325
      Wey-Yi Guy 提交于
      Support channel switch in driver as a separated mac80211 callback
      function instead of part of mac_config callback; by moving to this
      approach, uCode can have more control of channel switch timing.
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      79d07325
    • W
      iwlwifi: remove unused parameter in iwl_priv · ae0bce02
      Wey-Yi Guy 提交于
      restrict_refcnt is no longer used, remove it from iwl_priv
      structure
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      ae0bce02
    • J
      iwlwifi: remove mac_addr assignment · 30eabc17
      Johannes Berg 提交于
      priv->mac_addr is the address of the operating
      interface, not the permanent MAC address. They
      are usually the same, but the user can override
      the operating address, so we shouldn't set the
      variable to the permanent one, it is assigned
      when an interface is added.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      30eabc17
    • J
      iwlwifi: remove useless node_addr assignments · 041fa0cd
      Johannes Berg 提交于
      iwl_connection_init_rx_config() will already
      have set up the entire RXON command, so these
      assignments are duplicate.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      041fa0cd
    • E
      iwlwifi: move sysfs_create_group to post request firmware · 7d47618a
      Emmanuel Grumbach 提交于
      Move the sysfs_create_group to iwl_ucode_callback after we
      have safely got the firmware.
      
      The motivation to do this comes from a warning from lockdep which detected
      that we request priv->mutex while holding s_active during a sysfs request
      (show_statistics in the example copy pasted). The reverse order exists upon
      request_firmware: request_firmware which is a sysfs operation
      that requires s_active is run under priv->mutex.
      
      This ensures that we don't get sysfs request before we finish to request
      the firmware, avoiding this deadlock.
      
      =======================================================
      [ INFO: possible circular locking dependency detected ]
      -------------------------------------------------------
      cat/2595 is trying to acquire lock:
       (&priv->mutex){+.+.+.}, at: [<facfa598>] show_statistics+0x48/0x100 [iwlagn]
      
      but task is already holding lock:
       (s_active){++++.+}, at: [<c0580ebd>] sysfs_get_active_two+0x1d/0x50
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 (s_active){++++.+}:
             [<c0489b74>] __lock_acquire+0xc44/0x1230
             [<c048a1ed>] lock_acquire+0x8d/0x110
             [<c0581499>] sysfs_addrm_finish+0xe9/0x180
             [<c057f64a>] sysfs_hash_and_remove+0x4a/0x80
             [<c05829d4>] sysfs_remove_group+0x44/0xd0
             [<c0714b75>] dpm_sysfs_remove+0x15/0x20
             [<c070dac8>] device_del+0x38/0x170
             [<c070dc1e>] device_unregister+0x1e/0x60
             [<c071838d>] _request_firmware+0x29d/0x550
             [<c07186c7>] request_firmware+0x17/0x20
             [<fad01bf1>] iwl_mac_start+0xb1/0x1230 [iwlagn]
             [<fa46ba06>] ieee80211_open+0x436/0x6f0 [mac80211]
             [<c0808cd2>] dev_open+0x92/0xf0
             [<c0808b2b>] dev_change_flags+0x7b/0x190
             [<c08148e8>] do_setlink+0x178/0x3b0
             [<c0815169>] rtnl_setlink+0xf9/0x130
             [<c081453b>] rtnetlink_rcv_msg+0x1bb/0x1f0
             [<c0827ce6>] netlink_rcv_skb+0x86/0xa0
             [<c081436c>] rtnetlink_rcv+0x1c/0x30
             [<c08279c3>] netlink_unicast+0x263/0x290
             [<c0828768>] netlink_sendmsg+0x1c8/0x2a0
             [<c07f85fd>] sock_sendmsg+0xcd/0x100
             [<c07f964d>] sys_sendmsg+0x15d/0x290
             [<c07f9e6b>] sys_socketcall+0xeb/0x2a0
             [<c040ad9f>] sysenter_do_call+0x12/0x38
      
      -> #0 (&priv->mutex){+.+.+.}:
             [<c0489f84>] __lock_acquire+0x1054/0x1230
             [<c048a1ed>] lock_acquire+0x8d/0x110
             [<c08bb358>] __mutex_lock_common+0x58/0x470
             [<c08bb84a>] mutex_lock_nested+0x3a/0x50
             [<facfa598>] show_statistics+0x48/0x100 [iwlagn]
             [<c070d219>] dev_attr_show+0x29/0x50
             [<c057fecd>] sysfs_read_file+0xdd/0x190
             [<c052880f>] vfs_read+0x9f/0x190
             [<c0528d22>] sys_read+0x42/0x70
             [<c040ad9f>] sysenter_do_call+0x12/0x38
      
      other info that might help us debug this:
      
      3 locks held by cat/2595:
       #0:  (&buffer->mutex){+.+.+.}, at: [<c057fe25>] sysfs_read_file+0x35/0x190
       #1:  (s_active){++++.+}, at: [<c0580ecd>] sysfs_get_active_two+0x2d/0x50
       #2:  (s_active){++++.+}, at: [<c0580ebd>] sysfs_get_active_two+0x1d/0x50
      
      stack backtrace:
      Pid: 2595, comm: cat Not tainted 2.6.33-tp-rc4 #2
      Call Trace:
       [<c08b99ab>] ? printk+0x1d/0x22
       [<c0487752>] print_circular_bug+0xc2/0xd0
       [<c0489f84>] __lock_acquire+0x1054/0x1230
       [<c0478d81>] ? sched_clock_cpu+0x121/0x180
       [<c048a1ed>] lock_acquire+0x8d/0x110
       [<facfa598>] ? show_statistics+0x48/0x100 [iwlagn]
       [<c08bb358>] __mutex_lock_common+0x58/0x470
       [<facfa598>] ? show_statistics+0x48/0x100 [iwlagn]
       [<c08bb84a>] mutex_lock_nested+0x3a/0x50
       [<facfa598>] ? show_statistics+0x48/0x100 [iwlagn]
       [<facfa598>] show_statistics+0x48/0x100 [iwlagn]
       [<c0580cf9>] ? sysfs_get_active+0x69/0xb0
       [<facfa550>] ? show_statistics+0x0/0x100 [iwlagn]
       [<c070d219>] dev_attr_show+0x29/0x50
       [<c057fecd>] sysfs_read_file+0xdd/0x190
       [<c05ff314>] ? security_file_permission+0x14/0x20
       [<c0528242>] ? rw_verify_area+0x62/0xd0
       [<c052880f>] vfs_read+0x9f/0x190
       [<c047745b>] ? up_read+0x1b/0x30
       [<c057fdf0>] ? sysfs_read_file+0x0/0x190
       [<c04af3b4>] ? audit_syscall_entry+0x1f4/0x220
       [<c0528d22>] sys_read+0x42/0x70
       [<c040ad9f>] sysenter_do_call+0x12/0x38
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      7d47618a
  6. 05 6月, 2010 1 次提交
  7. 04 6月, 2010 1 次提交
    • J
      Revert "iwlwifi: move _agn statistics related structure" · 2daf6c15
      John W. Linville 提交于
      This reverts commit a2064b7a.
      
      when CONFIG_IWLAGN=n:
      
      drivers/net/wireless/iwlwifi/iwl-rx.c:254: error: 'struct iwl_priv' has no member named '_agn'
      drivers/net/wireless/iwlwifi/iwl-rx.c:303: error: 'struct iwl_priv' has no member named '_agn'
      drivers/net/wireless/iwlwifi/iwl-rx.c:304: error: 'struct iwl_priv' has no member named '_agn'
      drivers/net/wireless/iwlwifi/iwl-rx.c:305: error: 'struct iwl_priv' has no member named '_agn'
      drivers/net/wireless/iwlwifi/iwl-rx.c:306: error: 'struct iwl_priv' has no member named '_agn'
      
      and many more.
      
      Conflicts:
      
      	drivers/net/wireless/iwlwifi/iwl-agn-debugfs.c
      	drivers/net/wireless/iwlwifi/iwl-debugfs.c
      	drivers/net/wireless/iwlwifi/iwl-dev.h
      	drivers/net/wireless/iwlwifi/iwl-rx.c
      Reported-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2daf6c15
  8. 14 5月, 2010 8 次提交
  9. 11 5月, 2010 14 次提交