1. 01 2月, 2011 1 次提交
    • H
      rt2x00: Refactor beacon code to make use of start- and stop_queue · 69cf36a4
      Helmut Schaa 提交于
      This patch allows to dynamically remove beaconing interfaces without
      shutting beaconing down on all interfaces.
      
      The only place to start and stop beaconing are now the start- and
      stop_queue callbacks. Hence, we can remove some register writes during
      interface bring up (config_intf) and only write the correct sync mode
      to the register there.
      
      When multiple beaconing interfaces are present we should enable
      beaconing as soon as mac80211 enables beaconing on at least one of
      them. The beacon queue gets stopped when the last beaconing
      interface was stopped by mac80211. Therefore, introduce another
      interface counter to keep track ot the number of enabled beaconing
      interfaces and start or stop the beacon queue accordingly.
      
      To allow single interfaces to stop beaconing, add a new driver
      callback clear_beacon to clear a single interface's beacon without
      affecting the other interfaces. Don't overload the clear_entry callback
      for clearing beacons as that would introduce additional overhead
      (check for each TX queue) into the clear_entry callback which is used
      on the drivers TX/RX hotpaths.
      
      Furthermore, the write beacon callback doesn't need to enable beaconing
      anymore but since beaconing should be disabled while a new beacon is
      written or cleared we still disable beacon generation and enable it
      afterwards again in the driver specific callbacks. However, beacon
      related interrupts should not be disabled/enabled here, that's solely
      done from the start- and stop queue callbacks. It would be nice to stop
      the beacon queue just before the beacon update and enable it afterwards
      in rt2x00queue itself instead of the current implementation that relies
      on the driver doing the right thing. However, since start- and
      stop_queue are mutex protected we cannot use them for atomic beacon
      updates.
      Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
      Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
      Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      69cf36a4
  2. 26 1月, 2011 1 次提交
  3. 22 1月, 2011 1 次提交
    • B
      cfg80211: Extend channel to frequency mapping for 802.11j · 59eb21a6
      Bruno Randolf 提交于
      Extend channel to frequency mapping for 802.11j Japan 4.9GHz band, according to
      IEEE802.11 section 17.3.8.3.2 and Annex J. Because there are now overlapping
      channel numbers in the 2GHz and 5GHz band we can't map from channel to
      frequency without knowing the band. This is no problem as in most contexts we
      know the band. In places where we don't know the band (and WEXT compatibility)
      we assume the 2GHz band for channels below 14.
      
      This patch does not implement all channel to frequency mappings defined in
      802.11, it's just an extension for 802.11j 20MHz channels. 5MHz and 10MHz
      channels as well as 802.11y channels have been omitted.
      
      The following drivers have been updated to reflect the API changes:
      iwl-3945, iwl-agn, iwmc3200wifi, libertas, mwl8k, rt2x00, wl1251, wl12xx.
      The drivers have been compile-tested only.
      Signed-off-by: NBruno Randolf <br1@einfach.org>
      Signed-off-by: NBrian Prodoehl <bprodoehl@gmail.com>
      Acked-by: NLuciano Coelho <coelho@ti.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      59eb21a6
  4. 20 1月, 2011 3 次提交
  5. 14 1月, 2011 1 次提交
  6. 05 1月, 2011 10 次提交
  7. 24 12月, 2010 1 次提交
  8. 23 12月, 2010 1 次提交
  9. 21 12月, 2010 1 次提交
  10. 14 12月, 2010 17 次提交
  11. 01 12月, 2010 1 次提交
  12. 23 11月, 2010 1 次提交
  13. 18 11月, 2010 1 次提交