rt2x00: Update comment about the AMPDU flag in the TXWI
authorHelmut Schaa <helmut.schaa@googlemail.com>
Sat, 2 Oct 2010 09:33:42 +0000 (11:33 +0200)
committerJohn W. Linville <linville@tuxdriver.com>
Tue, 5 Oct 2010 17:35:28 +0000 (13:35 -0400)
During testing with AMPDUs it turned out that the rt2800 hw will aggregate
consecutive frames with the same RA and TID when the first frame in a
possible aggregate has set AMPDU=1 in the TXWI. If a following frame has
set AMPDU=0 in its TXWI it might sill end up in the aggregate of the
previous frame. Update the comment accordingly.

Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
drivers/net/wireless/rt2x00/rt2800.h

index 2a9f4020af1eaa62647cb25fcef76f95273b2184..eb8b6cab992516fa8bdf58d2feabcf44950585f3 100644 (file)
@@ -2003,7 +2003,13 @@ struct mac_iveiv_entry {
  *     duplicate the frame to both channels).
  * STBC: 1: STBC support MCS =0-7, 2,3 : RESERVED
  * AMPDU: 1: this frame is eligible for AMPDU aggregation, the hw will
- *        aggregate consecutive frames with the same RA and QoS TID.
+ *        aggregate consecutive frames with the same RA and QoS TID. If
+ *        a frame A with the same RA and QoS TID but AMPDU=0 is queued
+ *        directly after a frame B with AMPDU=1, frame A might still
+ *        get aggregated into the AMPDU started by frame B. So, setting
+ *        AMPDU to 0 does _not_ necessarily mean the frame is sent as
+ *        MPDU, it can still end up in an AMPDU if the previous frame
+ *        was tagged as AMPDU.
  */
 #define TXWI_W0_FRAG                   FIELD32(0x00000001)
 #define TXWI_W0_MIMO_PS                        FIELD32(0x00000002)