1. 03 Jun, 2009 1 commit
  2. 20 May, 2009 1 commit
    • Luis R. Rodriguez's avatar
      cfg80211: Process regulatory max bandwidth checks for HT40 · 038659e7
      Luis R. Rodriguez authored
      
      
      We are not correctly listening to the regulatory max bandwidth
      settings. To actually make use of it we need to redesign things
      a bit. This patch does the work for that. We do this to so we
      can obey to regulatory rules accordingly for use of HT40.
      
      We end up dealing with HT40 by having two passes for each channel.
      
      The first check will see if a 20 MHz channel fits into the channel's
      center freq on a given frequency range. We check for a 20 MHz
      banwidth channel as that is the maximum an individual channel
      will use, at least for now. The first pass will go ahead and
      check if the regulatory rule for that given center of frequency
      allows 40 MHz bandwidths and we use this to determine whether
      or not the channel supports HT40 or not. So to support HT40 you'll
      need at a regulatory rule that allows you to use 40 MHz channels
      but you're channel must also be enabled and support 20 MHz by itself.
      
      The second pass is done after we do the regulatory checks over
      an device's supported channel list. On each channel we'll check
      if the control channel and the extension both:
      
       o exist
       o are enabled
       o regulatory allows 40 MHz bandwidth on its frequency range
      
      This work allows allows us to idependently check for HT40- and
      HT40+.
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      038659e7
  3. 22 Apr, 2009 7 commits
  4. 27 Mar, 2009 1 commit
  5. 16 Mar, 2009 2 commits
  6. 05 Mar, 2009 1 commit
    • Jouni Malinen's avatar
      ath9k: Add data structure for supporting virtual radio/wiphy operation · bce048d7
      Jouni Malinen authored
      
      
      This is the initial step in allowing ath9k to register multiple
      virtual radios (wiphys). The goal of virtual radios is to allow the
      same radio to be shared for multiple virtual interfaces that may
      operate on different channels. The mac80211 virtual interface support
      is designed only for single channel operation and as such, it is not
      suitable for this type of use. Anyway, it can be used on top of the
      virtual radio concept, if desired (e.g., use two virtual radios to
      handle two channels and then add multiple mac80211 virtual interfaces
      on top of each virtual radio).
      
      The new struct ath_wiphy is now registered as the driver data
      structure for wiphy. This structure has a pointer to the shared (among
      virtual wiphys of the same physical radio) struct ath_softc data. The
      primary wiphy maintains the allocated memory for ath_softc. Secondary
      (virtual) wiphys will only allocate the new ath_wiphy structure.
      
      Registration of secondary wiphys is added in a separate patch.
      Signed-off-by: default avatarJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      bce048d7
  7. 27 Feb, 2009 6 commits
  8. 13 Feb, 2009 3 commits
  9. 09 Feb, 2009 4 commits
  10. 29 Jan, 2009 2 commits
    • Luis R. Rodriguez's avatar
      ath9k: fix debug print on regd · 0c6666e4
      Luis R. Rodriguez authored
      
      
      With debugging enabled and with ATH_DBG_REGULATORY
      selected we wouldn't get the full print out of one line,
      reason is we used "," instead of nothing to separate two
      lines.
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      0c6666e4
    • Luis R. Rodriguez's avatar
      ath9k: simplify regulatory code · 5f8e077c
      Luis R. Rodriguez authored
      
      
      Now that cfg80211 has its own regulatory infrastructure we can
      condense ath9k's regulatory code considerably. We only keep data
      we need to provide our own regulatory_hint(), reg_notifier() and
      information necessary for calibration.
      
      Atheros hardware supports 12 world regulatory domains, since these
      are custom we apply them through the the new wiphy_apply_custom_regulatory().
      Although we have 12 we can consolidate these into 5 structures based on
      frequency and apply a different set of flags that differentiate them on
      a case by case basis through the reg_notifier().
      
      If CRDA is not found our own custom world regulatory domain is applied,
      this is identical to cfg80211's except we enable passive scan on most
      frequencies.
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      5f8e077c
  11. 05 Dec, 2008 3 commits
  12. 07 Aug, 2008 3 commits