1. 12 10月, 2011 11 次提交
  2. 07 10月, 2011 4 次提交
  3. 05 10月, 2011 1 次提交
  4. 04 10月, 2011 13 次提交
  5. 03 10月, 2011 1 次提交
    • K
      ath6kl: include vmalloc.h in debug.c · 62c83ac4
      Kalle Valo 提交于
      Fixes compilation errors when compiling for ARM:
      
      ath6kl/debug.c:312: error: implicit declaration of function 'vmalloc'
      ath6kl/debug.c:312: warning: assignment makes pointer from integer without a cast
      ath6kl/debug.c:342: error: implicit declaration of function 'vfree'
      ath6kl/debug.c:696: warning: assignment makes pointer from integer without a cast
      ath6kl/debug.c:871: warning: assignment makes pointer from integer without a cast
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      62c83ac4
  6. 01 10月, 2011 10 次提交
    • K
      ath6kl: fix size_t related warnings · ef548626
      Kalle Valo 提交于
      My earlier debug log additions added these warnings when compiling 64 bit
      kernels:
      
      ath6kl/init.c:962: warning: format '%d' expects type 'int',
        but argument 3 has type 'size_t'
      ath6kl/init.c:975: warning: format '%d' expects type 'int',
        but argument 3 has type 'size_t'
      ath6kl/init.c:988: warning: format '%d' expects type 'int',
        but argument 3 has type 'size_t'
      ath6kl/init.c:1009: warning: format '%d' expects type 'int',
        but argument 3 has type 'size_t'
      ath6kl/init.c:1192: warning: format '%d' expects type 'int',
        but argument 4 has type 'size_t'
      ath6kl/init.c:1236: warning: format '%d' expects type 'int',
        but argument 4 has type 'size_t'
      ath6kl/init.c:1267: warning: format '%d' expects type 'int',
        but argument 4 has type 'size_t'
      Reported-by: NVasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      ef548626
    • J
      mac80211: dont assign seqno to or aggregate QoS Null frames · 49a59543
      Johannes Berg 提交于
      802.11 says:
      "Sequence numbers for QoS (+)Null frames may be
      set to any value."
      
      However, if we use the normal counters then peers
      will get confused with aggregation since there'll
      be holes in the sequence number sequence.
      
      To avoid that, neither assign a sequence number
      to QoS null frames nor put them on aggregation.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      49a59543
    • J
      mac80211: document client powersave · 4b801bc9
      Johannes Berg 提交于
      With the addition of uAPSD and driver buffering
      the powersave handling has gotten quite complex.
      Add a section to the documentation to explain it
      for anyone wanting to implement it.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4b801bc9
    • J
      mac80211: allow out-of-band EOSP notification · 37fbd908
      Johannes Berg 提交于
      iwlwifi has a separate EOSP notification from
      the device, and to make use of that properly
      it needs to be passed to mac80211. To be able
      to mix with tx_status_irqsafe and rx_irqsafe
      it also needs to be an "_irqsafe" version in
      the sense that it goes through the tasklet,
      the actual flag clearing would be IRQ-safe
      but doing it directly would cause reordering
      issues.
      
      This is needed in the case of a P2P GO going
      into an absence period without transmitting
      any frames that should be driver-released as
      in this case there's no other way to inform
      mac80211 that the service period ended. Note
      that for drivers that don't use the _irqsafe
      functions another version of this function
      will be required.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      37fbd908
    • J
      mac80211: explicitly notify drivers of frame release · 40b96408
      Johannes Berg 提交于
      iwlwifi needs to know the number of frames that are
      going to be sent to a station while it is asleep so
      it can properly handle the uCode blocking of that
      station.
      
      Before uAPSD, we got by by telling the device that
      a single frame was going to be released whenever we
      encountered IEEE80211_TX_CTL_POLL_RESPONSE. With
      uAPSD, however, that is no longer possible since
      there could be more than a single frame.
      
      To support this model, add a new callback to notify
      drivers when frames are going to be released.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      40b96408
    • J
      mac80211: add missing station flags to debugfs · 5bade101
      Johannes Berg 提交于
      My work and some previous work didn't add
      all the flags, add them now and while at it
      simplify the code.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5bade101
    • J
      mac80211: optimise station flags · c2c98fde
      Johannes Berg 提交于
      The flaglock in struct sta_info has long been
      something that I wanted to get rid of, this
      finally does the conversion to atomic bitops.
      
      The conversion itself is straight-forward in
      most places, a few things needed to change a
      bit since we can no longer use multiple bits
      at the same time.
      
      On x86-64, this is a fairly significant code
      size reduction:
         text	   data	    bss	    dec	    hex
       427861	  23648	   1008	 452517	  6e7a5	before
       425383	  23648	    976	 450007	  6ddd7	after
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c2c98fde
    • J
      mac80211: reply only once to each PS-poll · deeaee19
      Johannes Berg 提交于
      If a PS-poll frame is retried (but was received)
      there is no way to detect that since it has no
      sequence number. As a consequence, the standard
      asks us to not react to PS-poll frames until the
      response to one made it out (was ACKed or lost).
      
      Implement this by using the WLAN_STA_SP flags to
      also indicate a PS-Poll "service period" and the
      IEEE80211_TX_STATUS_EOSP flag for the response
      packet to indicate the end of the "SP" as usual.
      
      We could use separate flags, but that will most
      likely completely confuse drivers, and while the
      standard doesn't exclude simultaneously polling
      using uAPSD and PS-Poll, doing that seems quite
      problematic.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      deeaee19
    • J
      mac80211: send (QoS) Null if no buffered frames · ce662b44
      Johannes Berg 提交于
      For PS-poll, there's a possible race between
      us expiring a frame and the station polling
      for it -- send it a null frame in that case.
      
      For uAPSD, the standard says that we have to
      send a frame in each SP, so send null if we
      don't have any other frames.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ce662b44
    • J
      mac80211: implement uAPSD · 47086fc5
      Johannes Berg 提交于
      Add uAPSD support to mac80211. This is probably not
      possible with all devices, so advertising it with
      the cfg80211 flag will be left up to drivers that
      want it.
      
      Due to my previous patches it is now a fairly
      straight-forward extension. Drivers need to have
      accurate TX status reporting for the EOSP frame.
      For drivers that buffer themselves, the provided
      APIs allow releasing the right number of frames,
      but then drivers need to set EOSP and more-data
      themselves. This is documented in more detail in
      the new code itself.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      47086fc5