1. 11 3月, 2010 1 次提交
    • Z
      iwmc3200wifi: refuse to associate on unallowed channels · 7d49c611
      Zhu Yi 提交于
      We need to make sure we don't associate with APs on unallowed
      channels (according to regulatory setting). This could happen
      when the channel is not specified (auto-select) within the
      connection request. In this case we get the AP's channel until
      the firmware indicates the association succeeded later. We need
      to verify the associated channel. If the channel is disabled by
      regulatory, we have to disassociate with the AP.
      Signed-off-by: NZhu Yi <yi.zhu@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7d49c611
  2. 10 2月, 2010 1 次提交
  3. 23 12月, 2009 2 次提交
  4. 22 12月, 2009 1 次提交
  5. 04 12月, 2009 1 次提交
  6. 29 11月, 2009 1 次提交
    • S
      iwmc3200wifi: 802.11n Tx aggregation support · a7af530d
      Samuel Ortiz 提交于
      To support 802.11n Tx aggregation support with iwmc3200 wifi, we have to
      handle the UMAC_CMD_OPCODE_STOP_RESUME_STA_TX notification from the UMAC.
      Before sending an AddBA, the UMAC synchronizes with the host in order to
      know what is the last Tx frame it's supposed to receive before it will be
      able to start the actual aggregation session.
      We thus have to keep track of the last sequence number that is scheduled
      for transmission on a particular RAxTID, send an answer to the UMAC with
      this sequence number. The UMAC then does the BA negociation and once it's
      done with it sends a new UMAC_CMD_OPCODE_STOP_RESUME_STA_TX notification
      to let us know that we can resume the Tx flow on the specified RAxTID.
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      Reviewed-by: NZhu Yi <yi.zhu@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a7af530d
  7. 28 10月, 2009 6 次提交
  8. 12 10月, 2009 1 次提交
  9. 02 9月, 2009 5 次提交
  10. 25 7月, 2009 6 次提交
  11. 11 7月, 2009 4 次提交
  12. 23 5月, 2009 1 次提交