1. 06 3月, 2013 8 次提交
  2. 01 3月, 2013 1 次提交
    • J
      nl80211: increase wiphy dump size dynamically · 645e77de
      Johannes Berg 提交于
      Given a device with many channels capabilities the wiphy
      information can still overflow even though its size in
      3.9 was reduced to 3.8 levels. For new userspace and
      kernel 3.10 we're going to implement a new "split dump"
      protocol that can use multiple messages per wiphy.
      
      For now though, add a workaround to be able to send more
      information to userspace. Since generic netlink doesn't
      have a way to set the minimum dump size globally, and we
      wouldn't really want to set it globally anyway, increase
      the size only when needed, as described in the comments.
      As userspace might not be prepared for large buffers, we
      can only use 4k.
      
      Also increase the size for the get_wiphy command.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      645e77de
  3. 27 2月, 2013 1 次提交
  4. 26 2月, 2013 2 次提交
    • J
      nl80211: remove TCP WoWLAN information · 162589f7
      Johannes Berg 提交于
      Just like the radar information, the TCP WoWLAN capability
      data can increase the wiphy information and make it too
      big. Remove the TCP WoWLAN information; no driver supports
      it and new userspace tools will be required as well.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      162589f7
    • J
      nl80211: remove radar information · 1c33a059
      Johannes Berg 提交于
      The wiphy information is getting very close to being too
      much for a typical netlink dump message and adding the
      radar attributes to channels and interface combinations
      can push it over the limit, which means userspace gets no
      information whatsoever. Therefore, remove these again for
      now, no driver actually supports radar detection anyway
      and a modified userspace is required as well.
      
      We're working on a solution that will allow userspace to
      request splitting the information across multiple netlink
      messages, which will allow us to add this back.
      
      Cc: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      1c33a059
  5. 19 2月, 2013 1 次提交
  6. 15 2月, 2013 5 次提交
  7. 13 2月, 2013 2 次提交
  8. 12 2月, 2013 1 次提交
    • J
      cfg80211: move TSF into IEs · 8cef2c9d
      Johannes Berg 提交于
      While technically the TSF isn't an IE, it can be
      necessary to distinguish between the TSF from a
      beacon and a probe response, in particular in
      order to know the next DTIM TBTT, as not all APs
      are spec compliant wrt. TSF==0 being a DTIM TBTT
      and thus the DTIM count needs to be taken into
      account as well.
      
      To allow this, move the TSF into the IE struct
      so it can be known whence it came.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      8cef2c9d
  9. 05 2月, 2013 1 次提交
    • V
      cfg80211: expand per-station byte counters to 64bit · 42745e03
      Vladimir Kondratiev 提交于
      In per-station statistics, present 32bit counters are too small
      for practical purposes - with gigabit speeds, it get overlapped
      every few seconds.
      
      Expand counters in the struct station_info to be 64-bit.
      Driver can still fill only 32-bit and indicate in @filled
      only bits like STATION_INFO_[TR]X_BYTES; in case driver provides
      full 64-bit counter, it should also set in @filled
      bit STATION_INFO_[TR]RX_BYTES64
      
      Netlink sends both 32-bit and 64-bit counters, if present, to not
      break userspace.
      Signed-off-by: NVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
      [change to also have 32-bit counters if driver advertises 64-bit]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      42745e03
  10. 31 1月, 2013 1 次提交
  11. 26 1月, 2013 1 次提交
  12. 17 1月, 2013 6 次提交
  13. 03 1月, 2013 7 次提交
  14. 30 11月, 2012 2 次提交
  15. 29 11月, 2012 1 次提交