1. 12 12月, 2014 1 次提交
  2. 28 11月, 2014 1 次提交
    • F
      mac80211: copy chandef from AP vif to VLANs · 2967e031
      Felix Fietkau 提交于
      Instead of keeping track of all those special cases where
      VLAN interfaces have no bss_conf.chandef, just make sure
      they have the same as the AP interface they belong to.
      
      Among others, this fixes a crash getting a VLAN's channel
      from userspace since a NULL channel is returned as a good
      result (return value 0) for VLANs since the commit below.
      
      Cc: stable@vger.kernel.org [3.18 only]
      Fixes: c12bc488 ("mac80211: return the vif's chandef in ieee80211_cfg_get_channel()")
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      [rewrite commit log]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      2967e031
  3. 04 11月, 2014 2 次提交
    • R
      mac80211: 802.11p OCB mode support · 239281f8
      Rostislav Lisovy 提交于
      This patch adds 802.11p OCB (Outside the Context of a BSS) mode
      support.
      
      When communicating in OCB mode a mandatory wildcard BSSID
      (48 '1' bits) is used.
      
      The EDCA parameters handling function was changed to support
      802.11p specific values.
      
      The insertion of a newly discovered STAs is done in the similar way
      as in the IBSS mode -- through the deferred insertion.
      
      The OCB mode uses a periodic 'housekeeping task' for expiration of
      disconnected STAs (in the similar manner as in the MESH mode).
      
      New Kconfig option for verbose OCB debugging outputs is added.
      Signed-off-by: NRostislav Lisovy <rostislav.lisovy@fel.cvut.cz>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      239281f8
    • R
      cfg80211: 802.11p OCB mode handling · 6e0bd6c3
      Rostislav Lisovy 提交于
      This patch adds new iface type (NL80211_IFTYPE_OCB) representing
      the OCB (Outside the Context of a BSS) mode.
      When establishing a connection to the network a cfg80211_join_ocb
      function is called (particular nl80211_command is added as well).
      A mandatory parameters during the ocb_join operation are 'center
      frequency' and 'channel width (5/10 MHz)'.
      
      Changes done in mac80211 are minimal possible required to avoid
      many warnings (warning: enumeration value 'NL80211_IFTYPE_OCB'
      not handled in switch) during compilation. Full functionality
      (where needed) is added in the following patch.
      Signed-off-by: NRostislav Lisovy <rostislav.lisovy@fel.cvut.cz>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      6e0bd6c3
  4. 31 10月, 2014 1 次提交
  5. 29 8月, 2014 1 次提交
    • M
      mac80211: fix chantype recalc warning · a00f4f6e
      Michal Kazior 提交于
      When a device driver is unloaded local->interfaces
      list is cleared. If there was more than 1
      interface running and connected (bound to a
      chanctx) then chantype recalc was called and it
      ended up with compat being NULL causing a call
      trace warning.
      
      Warn if compat becomes NULL as a result of
      incompatible bss_conf.chandef of interfaces bound
      to a given channel context only.
      
      The call trace looked like this:
      
       WARNING: CPU: 2 PID: 2594 at /devel/src/linux/net/mac80211/chan.c:557 ieee80211_recalc_chanctx_chantype+0x2cd/0x2e0()
       Modules linked in: ath10k_pci(-) ath10k_core ath
       CPU: 2 PID: 2594 Comm: rmmod Tainted: G        W     3.16.0-rc1+ #150
       Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
        0000000000000009 ffff88001ea279c0 ffffffff818dfa93 0000000000000000
        ffff88001ea279f8 ffffffff810514a8 ffff88001ce09cd0 ffff88001e03cc58
        0000000000000000 ffff88001ce08840 ffff88001ce09cd0 ffff88001ea27a08
       Call Trace:
        [<ffffffff818dfa93>] dump_stack+0x4d/0x66
        [<ffffffff810514a8>] warn_slowpath_common+0x78/0xa0
        [<ffffffff81051585>] warn_slowpath_null+0x15/0x20
        [<ffffffff818a407d>] ieee80211_recalc_chanctx_chantype+0x2cd/0x2e0
        [<ffffffff818a3dda>] ? ieee80211_recalc_chanctx_chantype+0x2a/0x2e0
        [<ffffffff818a4919>] ieee80211_assign_vif_chanctx+0x1a9/0x770
        [<ffffffff818a6220>] __ieee80211_vif_release_channel+0x70/0x130
        [<ffffffff818a6dd3>] ieee80211_vif_release_channel+0x43/0xb0
        [<ffffffff81885f4e>] ieee80211_stop_ap+0x21e/0x5a0
        [<ffffffff8184b9b5>] __cfg80211_stop_ap+0x85/0x520
        [<ffffffff8181c188>] __cfg80211_leave+0x68/0x120
        [<ffffffff8181c268>] cfg80211_leave+0x28/0x40
        [<ffffffff8181c5f3>] cfg80211_netdev_notifier_call+0x373/0x6b0
        [<ffffffff8107f965>] notifier_call_chain+0x55/0x110
        [<ffffffff8107fa41>] raw_notifier_call_chain+0x11/0x20
        [<ffffffff816a8dc0>] call_netdevice_notifiers_info+0x30/0x60
        [<ffffffff816a8eb9>] __dev_close_many+0x59/0xf0
        [<ffffffff816a9021>] dev_close_many+0x81/0x120
        [<ffffffff816aa1c5>] rollback_registered_many+0x115/0x2a0
        [<ffffffff816aa3a6>] unregister_netdevice_many+0x16/0xa0
        [<ffffffff8187d841>] ieee80211_remove_interfaces+0x121/0x1b0
        [<ffffffff8185e0e6>] ieee80211_unregister_hw+0x56/0x110
        [<ffffffffa0011ac4>] ath10k_mac_unregister+0x14/0x60 [ath10k_core]
        [<ffffffffa0014fe7>] ath10k_core_unregister+0x27/0x40 [ath10k_core]
        [<ffffffffa003b1f4>] ath10k_pci_remove+0x44/0xa0 [ath10k_pci]
        [<ffffffff81373138>] pci_device_remove+0x28/0x60
        [<ffffffff814cb534>] __device_release_driver+0x64/0xd0
        [<ffffffff814cbcc8>] driver_detach+0xb8/0xc0
        [<ffffffff814cb23a>] bus_remove_driver+0x4a/0xb0
        [<ffffffff814cc697>] driver_unregister+0x27/0x50
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      a00f4f6e
  6. 26 8月, 2014 2 次提交
  7. 23 8月, 2014 1 次提交
  8. 18 7月, 2014 1 次提交
  9. 26 6月, 2014 3 次提交
  10. 05 5月, 2014 1 次提交
  11. 25 4月, 2014 9 次提交
  12. 09 4月, 2014 9 次提交
  13. 03 3月, 2014 1 次提交
  14. 05 2月, 2014 1 次提交
  15. 19 12月, 2013 1 次提交
    • J
      mac80211: fix iflist_mtx/mtx locking in radar detection · 34a3740d
      Johannes Berg 提交于
      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: NKalle Valo <kvalo@qca.qualcomm.com>
      Tested-by: NSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      34a3740d
  16. 18 12月, 2013 1 次提交
  17. 26 11月, 2013 2 次提交
  18. 03 10月, 2013 1 次提交
  19. 02 8月, 2013 1 次提交