1. 20 4月, 2011 1 次提交
  2. 05 4月, 2011 5 次提交
  3. 05 3月, 2011 5 次提交
  4. 22 2月, 2011 5 次提交
  5. 15 2月, 2011 1 次提交
  6. 01 2月, 2011 3 次提交
  7. 20 1月, 2011 3 次提交
  8. 14 12月, 2010 3 次提交
  9. 23 11月, 2010 1 次提交
  10. 18 11月, 2010 1 次提交
  11. 16 11月, 2010 6 次提交
  12. 12 10月, 2010 1 次提交
  13. 06 10月, 2010 5 次提交
    • H
      rt2x00: Work around hw aggregation oddity in rt2800 · b34793ee
      Helmut Schaa 提交于
      If a frame is not meant to be sent as AMPDU or part of it the hw might
      still decide to aggregate this frame if a previous frame started an
      AMPDU. However, this will limit the usefulness of the reported tx rate
      since the reported rate will be the one specified in the TXWI of the
      first frame and thus it is not possible to reliably caculate the
      number of retrys by substracting the reported tx rate from the tx rate
      in the TXWI.
      
      To fix this issue, only report the successful rate for frames that were
      not meant to be aggregated but ended up in an aggregate.
      
      Example:
      Frame A (MCS7, AMPDU=1) B (MCS7, AMPDU=1) C (MCS12, AMDPU=0, PROBE_RATE)
      
      Although frame C shoudn't be aggregated the hw might sill put it
      into an AMPDU together with A and B. If the transmission succeeds the tx
      status will contain MCS7 for all three frames. In that case we should
      only report MCS7 as success rate and avoid reporting MCS12-MCS8 as
      failed tx attempts as this will affect the future rate control
      decisions.
      
      This oddity might strike us in other scenarious as well but the most
      common "wrong" report happened for frames used to probe a different tx
      rate.
      
      This improves the rate control decisions notable.
      Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
      Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b34793ee
    • H
      58ed826e
    • I
      rt2x00: Improve TX status entry validation · bc8a979e
      Ivo van Doorn 提交于
      The TX_STA_FIFO contains some information for identifying
      a outgoing frame, however matching by WCID and ACK status is
      not sufficient to 100% identify the macthing queue_entry structure
      (containing the SKB buffer) which belongs to the status report.
      
      Within TX_STA_FIFO we have a 4-bit field named PACKETID, which is
      currently used to encode the queue id. The queue ID is however
      limited to values from 0 to 3, which means 2 bits are sufficient
      to encode the value. With the remaining 2 bits we can encode a
      partial queue_entry index number. The value of PACKETID is not
      allowed to become 0, with the queue ID ranging from 0 to 3, at least
      one of the bits for the entry identification must be 1.
      
      That leaves us with 3 possible values we can still encode in the
      bits. Altough this doesn't allow 100% accurate matching of the
      TX_STA_FIFO queue to a queue_entry structure, it at least improves
      the accuracy. This allows us to better detect if we have missed the
      TX_STA_FIFO report, which in turn reduces the number of watchdog
      warnings regarding the TX status timeout.
      Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      bc8a979e
    • H
      rt2x00: correctly set max_report_rates in rt61pci and rt2800 · ba3b9e5e
      Helmut Schaa 提交于
      rt61pci and rt2800 devices can use up to 7 different rates per tx frame.
      However, the device uses a global fallback table. Hence, the rc
      algortihm cannot specify multiple rates to try but the device is able to
      report multiple rates (based on the retry table). Specify that behavior
      by correctly setting max_report_rates and max_rates.
      
      This makes rt2x00 and minstrel play nicer together.
      Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
      Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ba3b9e5e
    • H
      rt2x00: Don't enable broad- and multicast buffering on USB devices · 5a5b6ed6
      Helmut Schaa 提交于
      Since rt2x00 USB devices have no chance to know when a beacon was sent
      out in AP mode currently all broad- and multicast traffic is buffered in
      mac80211 but never sent out at all.
      
      Unfortunately we have no chance in sending the traffic out after a
      DTIM beacon due to hw limitations. Hence, instead of never sending the
      buffered traffic out better send it out immediately.
      Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
      Reported-by: NLauri Hintsala <lauri.hintsala@bluegiga.com>
      Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5a5b6ed6