1. 23 6月, 2014 18 次提交
  2. 09 6月, 2014 1 次提交
  3. 28 5月, 2014 4 次提交
  4. 27 5月, 2014 1 次提交
  5. 26 5月, 2014 2 次提交
    • E
      mac80211: fix virtual monitor interface addition · 34171dc0
      Emmanuel Grumbach 提交于
      Since the commit below, cfg80211_chandef_dfs_required()
      will warn if it gets a an NL80211_IFTYPE_UNSPECIFIED iftype
      as explicitely written in the commit log.
      When an virtual monitor interface is added, its type is set
      in ieee80211_sub_if_data.vif.type, but not in
      ieee80211_sub_if_data.wdev.iftype which is passed to
      cfg80211_chandef_dfs_required() hence resulting in the
      following warning:
      
      WARNING: CPU: 1 PID: 21265 at net/wireless/chan.c:376 cfg80211_chandef_dfs_required+0xbc/0x130 [cfg80211]()
      Modules linked in: [...]
      CPU: 1 PID: 21265 Comm: ifconfig Tainted: G        W  O 3.13.11+ #12
      Hardware name: Dell Inc. Latitude E6410/0667CC, BIOS A01 03/05/2010
       0000000000000009 ffff88008f5fdb08 ffffffff817d4219 ffff88008f5fdb50
       ffff88008f5fdb40 ffffffff8106f57d 0000000000000000 0000000000000000
       ffff880081062fb8 ffff8800810604e0 0000000000000001 ffff88008f5fdba0
      Call Trace:
       [<ffffffff817d4219>] dump_stack+0x4d/0x66
       [<ffffffff8106f57d>] warn_slowpath_common+0x7d/0xa0
       [<ffffffff8106f5ec>] warn_slowpath_fmt+0x4c/0x50
       [<ffffffffa04ea4ec>] cfg80211_chandef_dfs_required+0xbc/0x130 [cfg80211]
       [<ffffffffa06b1024>] ieee80211_vif_use_channel+0x94/0x500 [mac80211]
       [<ffffffffa0684e6b>] ieee80211_add_virtual_monitor+0x1ab/0x5c0 [mac80211]
       [<ffffffffa0686ae5>] ieee80211_do_open+0xe75/0x1580 [mac80211]
       [<ffffffffa0687259>] ieee80211_open+0x69/0x70 [mac80211]
      [snip]
      
      Fixes: 00ec75fc ("cfg80211: pass the actual iftype when calling cfg80211_chandef_dfs_required()")
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Acked-by: NLuciano Coelho <luciano.coelho@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      34171dc0
    • L
      mac80211: add a single-transaction driver op to switch contexts · 1a5f0c13
      Luciano Coelho 提交于
      In some cases, when the driver is already using all the channel
      contexts it can handle at once, we have to do an in-place switch
      (ie. we cannot afford using an extra context temporarily for the
      transaction).  But some drivers may not support switching the channel
      context assigned to a vif on the fly (ie. without unassigning and
      assigning it) while others may only work if the context is changed on
      the fly, without unassigning it first.
      
      To allow these different scenarios, add a new driver operation that
      let's the driver decide how to handle an in-place switch.
      Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      1a5f0c13
  6. 21 5月, 2014 1 次提交
    • A
      mac80211: export the expected throughput · cca674d4
      Antonio Quartulli 提交于
      Add get_expected_throughput() API to mac80211 so that each
      driver can implement its own version based on the RC
      algorithm they are using (might be using an HW RC algo).
      The API returns a value expressed in Kbps.
      
      Also, add the new get_expected_throughput() member
      to the rate_control_ops structure in order to be
      able to query the RC algorithm (this patch provides an
      implementation of this API for both minstrel and
      minstrel_ht).
      
      The related member in the station_info object is now
      filled accordingly when dumping a station.
      
      Cc: Felix Fietkau <nbd@openwrt.org>
      Signed-off-by: NAntonio Quartulli <antonio@open-mesh.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      cca674d4
  7. 19 5月, 2014 2 次提交
  8. 15 5月, 2014 5 次提交
  9. 14 5月, 2014 1 次提交
    • J
      mac80211: fix on-channel remain-on-channel · b4b177a5
      Johannes Berg 提交于
      Jouni reported that if a remain-on-channel was active on the
      same channel as the current operating channel, then the ROC
      would start, but any frames transmitted using mgmt-tx on the
      same channel would get delayed until after the ROC.
      
      The reason for this is that the ROC starts, but doesn't have
      any handling for "remain on the same channel", so it stops
      the interface queues. The later mgmt-tx then puts the frame
      on the interface queues (since it's on the current operating
      channel) and thus they get delayed until after the ROC.
      
      To fix this, add some logic to handle remaining on the same
      channel specially and not stop the queues etc. in this case.
      This not only fixes the bug but also improves behaviour in
      this case as data frames etc. can continue to flow.
      
      Cc: stable@vger.kernel.org
      Reported-by: NJouni Malinen <j@w1.fi>
      Tested-by: NJouni Malinen <j@w1.fi>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      b4b177a5
  10. 13 5月, 2014 1 次提交
  11. 09 5月, 2014 3 次提交
  12. 08 5月, 2014 1 次提交