1. 03 1月, 2013 9 次提交
  2. 30 11月, 2012 1 次提交
  3. 27 11月, 2012 1 次提交
  4. 26 11月, 2012 2 次提交
    • J
      mac80211: convert to channel definition struct · 4bf88530
      Johannes Berg 提交于
      Convert mac80211 (and where necessary, some drivers a
      little bit) to the new channel definition struct.
      
      This will allow extending mac80211 for VHT, which is
      currently restricted to channel contexts since there
      are no drivers using that which makes it easier. As
      I also don't care about VHT for drivers not using the
      channel context API, I won't convert the previous API
      to VHT support.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      4bf88530
    • J
      cfg80211: remove remain-on-channel channel type · 42d97a59
      Johannes Berg 提交于
      As mwifiex (and mac80211 in the software case) are the
      only drivers actually implementing remain-on-channel
      with channel type, userspace can't be relying on it.
      This is the case, as it's used only for P2P operations
      right now.
      
      Rather than adding a flag to tell userspace whether or
      not it can actually rely on it, simplify all the code
      by removing the ability to use different channel types.
      Leave only the validation of the attribute, so that if
      we extend it again later (with the needed capability
      flag), it can't break userspace sending invalid data.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      42d97a59
  5. 23 11月, 2012 1 次提交
  6. 14 11月, 2012 1 次提交
  7. 11 11月, 2012 1 次提交
  8. 06 11月, 2012 1 次提交
  9. 30 10月, 2012 2 次提交
    • 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: 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
  10. 19 10月, 2012 1 次提交
    • M
      mac80211: make client powersave independent of interface type · d012a605
      Marco Porsch 提交于
      This patch prepares mac80211 for a later implementation of mesh or
      ad-hoc powersave clients.
      The structures related to powersave (buffer, TIM map, counters) are
      moved from the AP-specific interface structure to a generic structure
      that can be embedded into any interface type.
      The functions related to powersave are prepared to allow easy
      extension with different interface types. For example with:
      
      + } else if (sta->sdata->vif.type == NL80211_IFTYPE_MESH_POINT) {
      +         ps = &sdata->u.mesh.ps;
      
      Some references to the AP's beacon structure are removed where they
      were obviously not used.
      
      The patch compiles without warning and has been briefly tested as AP
      interface with one client in PS mode.
      Signed-off-by: NMarco Porsch <marco.porsch@etit.tu-chemnitz.de>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      d012a605
  11. 18 10月, 2012 2 次提交
  12. 17 10月, 2012 8 次提交
  13. 14 9月, 2012 1 次提交
    • J
      mac80211: handle power constraint/country IE better · 04b7b2ff
      Johannes Berg 提交于
      Currently, mac80211 uses the power constraint IE, and reduces
      the regulatory max TX power by it. This can cause issues if
      the AP is advertising a large power constraint value matching
      a high TX power in its country IE, for example in this case:
      
      ...
      Country: US  Environment: Indoor/Outdoor
          ...
          Channels [157 - 157] @ 30 dBm
          ...
      Power constraint: 13 dB
      ...
      
      What happened here is that our local regulatory TX power is
      15 dBm, and gets reduced by 13 dB so we end up with only
      2 dBm effective TX power, which is way too low.
      
      Instead, handle the country IE/power constraint IE combined
      and restrict our TX power to the max of the regulatory power
      and the maximum power advertised by the AP, in this case
      17 dBm (= 30 dBm - 13 dB).
      
      Also print a message when this happens to let the user know
      and help us debug issues with it.
      Reported-by: NCarl A. Cook <CACook@quantum-equities.com>
      Tested-by: NCarl A. Cook <CACook@quantum-equities.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      04b7b2ff
  14. 11 9月, 2012 1 次提交
  15. 07 9月, 2012 1 次提交
  16. 06 9月, 2012 3 次提交
  17. 20 8月, 2012 4 次提交