1. 12 10月, 2011 16 次提交
  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 5 次提交
    • 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