1. 23 11月, 2012 1 次提交
  2. 21 11月, 2012 1 次提交
  3. 20 11月, 2012 1 次提交
    • J
      mac80211: fix channel context suspend/reconfig handling · fe5f2559
      Johannes Berg 提交于
      Sujith reported warnings with suspend/resume due to
      channel contexts. When I looked into it, I realised
      that the code was completely broken as it unassigned
      the channel contexts when suspending, which actually
      means they are destroyed.
      
      Eliad Peller then pointed out that we also need to
      remove the channel contexts from the driver. When I
      looked into this, I also noticed that the code isn't
      handling the virtual monitor interface correctly (if
      it exists.)
      
      Fix this by calling just the driver methods (if they
      are implemented) instead of using the channel context
      management code. Also add reconfiguration for the
      virtual monitor interface.
      Reported-by: NSujith Manoharan <sujith@msujith.org>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      fe5f2559
  4. 19 11月, 2012 6 次提交
  5. 14 11月, 2012 1 次提交
  6. 12 11月, 2012 1 次提交
  7. 10 11月, 2012 5 次提交
  8. 08 11月, 2012 7 次提交
  9. 06 11月, 2012 2 次提交
  10. 05 11月, 2012 5 次提交
  11. 30 10月, 2012 10 次提交
    • J
      mac80211: use a counter for remain-on-channel cookie · 50febf6a
      Johannes Berg 提交于
      Instead of using the pointer which can be re-used
      fairly quickly due to allocator patterns and then
      makes debugging difficult, maintain a counter and
      use its value. Since it's a 64-bit value it can't
      really wrap, but catch that case anyway since it
      most likely points to a bug somewhere.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      50febf6a
    • J
      mac80211: combine status/drop reporting · 8a2fbedc
      Johannes Berg 提交于
      The TX status reporting is done for both the
      nl80211 report as well as the socket option.
      The socket option is also reported when an
      skb is dropped to guarantee that the copy in
      the IDR tree is freed and status is reported
      to userspace.
      
      However, when a frame is dropped, no nl80211
      status is reported. This can cause userspace
      to stop making progress while waiting for a
      status notification.
      
      Combine the nl80211 and socket option status
      reporting into a new function and call it in
      both places -- when the status comes in from
      the driver and when the skb is dropped.
      
      While at it, also simplify the code in the
      nl80211 portion a bit.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      8a2fbedc
    • J
      mac80211_hwsim: print per interface TX power · cbc668a7
      Johannes Berg 提交于
      Just for debugging, print the interface TX
      power whenever it changes.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      cbc668a7
    • J
      mac80211: handle TX power per virtual interface · 1ea6f9c0
      Johannes Berg 提交于
      Even before channel contexts/multi-channel, having a
      single global TX power limit was already problematic,
      in particular if two managed interfaces connected to
      two APs with different power constraints. The channel
      context introduction completely broke this though and
      in fact I had disabled TX power configuration there
      for drivers using channel contexts.
      
      Change everything to track TX power per interface so
      that different user settings and different channel
      maxima are treated correctly. Also continue tracking
      the global TX power though for compatibility with
      applications that attempt to configure the wiphy's
      TX power globally.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      1ea6f9c0
    • J
      cfg80211: allow per interface TX power setting · c8442118
      Johannes Berg 提交于
      The TX power setting is currently per wiphy (hardware
      device) but with multi-channel capabilities that doesn't
      make much sense any more.
      
      Allow drivers (and mac80211) to advertise support for
      per-interface TX power configuration. When the TX power
      is configured for the wiphy, the wdev will be NULL and
      the driver can still handle that, but when a wdev is
      given the TX power can be set only for that wdev now.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      c8442118
    • J
      nl80211: move "can set channel" check · 71fe96bf
      Johannes Berg 提交于
      Setting the wdev to NULL when the channel can't be
      set for that interface type (to treat the channel
      setting for the wiphy/monitor) currently works, but
      is confusing in the code if netdev/wdev aren't both
      set/unset in the same way. Move the check whether
      the channel can be set to where it's needed so that
      wdev and netdev are always both assigned or NULL.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      71fe96bf
    • J
      mac80211_hwsim: allow using channel contexts · e8261171
      Johannes Berg 提交于
      To use mac80211_hwsim for testing channel contexts it
      has to support them, and for that it has to support
      hw scan and hw-remain-on-channel.
      
      Since it's pure software, the off-channel activities
      are really not off-channel but listening and sending
      on a second channel. Also, the multi-channel isn't
      really doing TDM, it's just on both channels at the
      same time.
      
      For testing purposes, you can specify the number of
      concurrent channels with a module parameter, it is
      set to one by default. When set to two or more, the
      userspace API for wmediumd is disabled as it has no
      provisions for multi-channel yet.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      e8261171
    • J
    • J
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless · ab3d59d2
      John W. Linville 提交于
      Conflicts:
      	drivers/net/wireless/mwifiex/cfg80211.c
      ab3d59d2
    • H
      ssb: handle BCM43222 in pmu code. · 42d36074
      Hauke Mehrtens 提交于
      The BCM43222 with the chipid 43222 or 0xa8d6 in hex do not need any
      special handling in the pmu code. This prevents some error messages
      being shown.
      Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      42d36074