1. 09 Apr, 2014 3 commits
  2. 03 Mar, 2014 1 commit
  3. 25 Feb, 2014 1 commit
  4. 20 Feb, 2014 1 commit
    • Sunil Dutt Undekari's avatar
      cfg80211: Pass TDLS peer capability information in tdls_mgmt · df942e7b
      Sunil Dutt Undekari authored
      
      
      While framing the TDLS Setup Confirmation frame, the driver needs to
      know if the TDLS peer is VHT/HT/WMM capable and thus shall construct
      the VHT/HT operation / WMM parameter elements accordingly. Supplicant
      determines if the TDLS peer is VHT/HT/WMM capable based on the
      presence of the respective IEs in the received TDLS Setup Response frame.
      
      The host driver should not need to parse the received TDLS Response
      frame and thus, should be able to rely on the supplicant to indicate
      the capability of the peer through additional flags while transmitting
      the TDLS Setup Confirmation frame through tdls_mgmt operations.
      Signed-off-by: default avatarSunil Dutt Undekari <usdutt@qti.qualcomm.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      df942e7b
  5. 06 Feb, 2014 5 commits
    • Johannes Berg's avatar
      mac80211: remove superfluous band variable · 4bf332c7
      Johannes Berg authored
      
      
      We already have a band variable, so the new one is just
      shadowing it, but the existing one already holds the
      same value so just remove the inner one.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      4bf332c7
    • Emmanuel Grumbach's avatar
      mac80211: release the channel in error path in start_ap · 0297ea17
      Emmanuel Grumbach authored
      
      
      When the driver cannot start the AP or when the assignement
      of the beacon goes wrong, we need to unassign the vif.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      0297ea17
    • Emmanuel Grumbach's avatar
      mac80211: avoid deadlock revealed by lockdep · 8ffcc704
      Emmanuel Grumbach authored
      sdata->u.ap.request_smps_work can’t be flushed synchronously
      under wdev_lock(wdev) since ieee80211_request_smps_ap_work
      itself locks the same lock.
      While at it, reset the driver_smps_mode when the ap is
      stopped to its default: OFF.
      
      This solves:
      
      ======================================================
      [ INFO: possible circular locking dependency detected ]
      3.12.0-ipeer+ #2 Tainted: G           O
      -------------------------------------------------------
      rmmod/2867 is trying to acquire lock:
        ((&sdata->u.ap.request_smps_work)){+.+...}, at: [<c105b8d0>] flush_work+0x0/0x90
      
      but task is already holding lock:
        (&wdev->mtx){+.+.+.}, at: [<f9b32626>] cfg80211_stop_ap+0x26/0x230 [cfg80211]
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 (&wdev->mtx){+.+.+.}:
              [<c10aefa9>] lock_acquire+0x79/0xe0
              [<c1607a1a>] mutex_lock_nested+0x4a/0x360
              [<fb06288b>] ieee80211_request_smps_ap_work+0x2b/0x50 [mac80211]
              [<c105cdd8>] process_one_work+0x198/0x450
              [<c105d469>] worker_thread+0xf9/0x320
              [<c10669ff>] kthread+0x9f/0xb0
              [<c1613397>] ret_from_kernel_thread+0x1b/0x28
      
      -> #0 ((&sdata->u.ap.request_smps_work)){+.+...}:
              [<c10ae9df>] __lock_acquire+0x183f/0x1910
              [<c10aefa9>] lock_acquire+0x79/0xe0
              [<c105b917>] flush_work+0x47/0x90
              [<c105d867>] __cancel_work_timer+0x67/0xe0
              [<c105d90f>] cancel_work_sync+0xf/0x20
              [<fb0765cc>] ieee80211_stop_ap+0x8c/0x340 [mac80211]
              [<f9b3268c>] cfg80211_stop_ap+0x8c/0x230 [cfg80211]
              [<f9b0d8f9>] cfg80211_leave+0x79/0x100 [cfg80211]
              [<f9b0da72>] cfg80211_netdev_notifier_call+0xf2/0x4f0 [cfg80211]
              [<c160f2c9>] notifier_call_chain+0x59/0x130
              [<c106c6de>] __raw_notifier_call_chain+0x1e/0x30
              [<c106c70f>] raw_notifier_call_chain+0x1f/0x30
              [<c14f8213>] call_netdevice_notifiers_info+0x33/0x70
              [<c14f8263>] call_netdevice_notifiers+0x13/0x20
              [<c14f82a4>] __dev_close_many+0x34/0xb0
              [<c14f83fe>] dev_close_many+0x6e/0xc0
              [<c14f9c77>] rollback_registered_many+0xa7/0x1f0
              [<c14f9dd4>] unregister_netdevice_many+0x14/0x60
              [<fb06f4d9>] ieee80211_remove_interfaces+0xe9/0x170 [mac80211]
              [<fb055116>] ieee80211_unregister_hw+0x56/0x110 [mac80211]
              [<fa3e9396>] iwl_op_mode_mvm_stop+0x26/0xe0 [iwlmvm]
              [<f9b9d8ca>] _iwl_op_mode_stop+0x3a/0x70 [iwlwifi]
              [<f9b9d96f>] iwl_opmode_deregister+0x6f/0x90 [iwlwifi]
              [<fa405179>] __exit_compat+0xd/0x19 [iwlmvm]
              [<c10b8bf9>] SyS_delete_module+0x179/0x2b0
              [<c1613421>] sysenter_do_call+0x12/0x32
      
      Fixes: 687da132
      
       ("mac80211: implement SMPS for AP")
      Cc: <stable@vger.kernel.org> [3.13]
      Reported-by: default avatarIlan Peer <ilan.peer@intel.com>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      8ffcc704
    • Eliad Peller's avatar
      mac80211: move roc cookie assignment earlier · 2f617435
      Eliad Peller authored
      
      
      ieee80211_start_roc_work() might add a new roc
      to existing roc, and tell cfg80211 it has already
      started.
      
      However, this might happen before the roc cookie
      was set, resulting in REMAIN_ON_CHANNEL (started)
      event with null cookie. Consequently, it can make
      wpa_supplicant go out of sync.
      
      Fix it by setting the roc cookie earlier.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarEliad Peller <eliad@wizery.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      2f617435
    • Emmanuel Grumbach's avatar
      mac80211: move VHT related RX_FLAG to another variable · 1b8d242a
      Emmanuel Grumbach authored
      
      
      ieee80211_rx_status.flags is full. Define a new vht_flag
      variable to be able to set more VHT related flags and make
      room in flags.
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Acked-by: Kalle Valo <kvalo@qca.qualcomm.com> [ath10k]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      1b8d242a
  6. 05 Feb, 2014 1 commit
  7. 04 Feb, 2014 10 commits
  8. 06 Jan, 2014 1 commit
  9. 30 Dec, 2013 1 commit
  10. 19 Dec, 2013 3 commits
    • Kyeyoon Park's avatar
      mac80211: Add support for QoS mapping · 32db6b54
      Kyeyoon Park authored
      
      
      Implement set_qos_map() handler for mac80211 to enable QoS mapping
      functionality.
      Signed-off-by: default avatarKyeyoon Park <kyeyoonp@qca.qualcomm.com>
      Signed-off-by: default avatarJouni Malinen <jouni@qca.qualcomm.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      32db6b54
    • Johannes Berg's avatar
      mac80211: fix iflist_mtx/mtx locking in radar detection · 34a3740d
      Johannes Berg authored
      
      
      The scan code creates an iflist_mtx -> mtx locking dependency,
      and a few other places, notably radar detection, were creating
      the opposite dependency, causing lockdep to complain. As scan
      and radar detection are mutually exclusive, the deadlock can't
      really happen in practice, but it's still bad form.
      
      A similar issue exists in the monitor mode code, but this is
      only used by channel-context drivers right now and those have
      to have hardware scan, so that also can't happen.
      
      Still, fix these issues by making some of the channel context
      code require the mtx to be held rather than acquiring it, thus
      allowing the monitor/radar callers to keep the iflist_mtx->mtx
      lock ordering.
      
      While at it, also fix access to the local->scanning variable
      in the radar code, and document that radar_detect_enabled is
      now properly protected by the mtx.
      
      All this would now introduce an ABBA deadlock between the DFS
      work cancelling and local->mtx, so change the locking there a
      bit to not need to use cancel_delayed_work_sync() but be able
      to just use cancel_delayed_work(). The work is also safely
      stopped/removed when the interface is stopped, so no extra
      changes are needed.
      Reported-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      Tested-by: default avatarSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      34a3740d
    • Johannes Berg's avatar
      mac80211: remove unnecessary iflist_mtx locking · 6924d013
      Johannes Berg authored
      
      
      The radar detection code changed a few times, and due to
      the changes some iflist_mtx locking stayed in that isn't
      actually necessary - remove it.
      
      One version of the code needed it because an AP interface's
      VLAN list was changed to use this, but then we moved the
      list handling outside of the chanctx handling and thus the
      locking was no longer needed.
      Tested-by: default avatarSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      6924d013
  11. 16 Dec, 2013 7 commits
  12. 05 Dec, 2013 1 commit
  13. 02 Dec, 2013 5 commits