1. 20 11月, 2009 1 次提交
  2. 22 7月, 2009 1 次提交
    • L
      ath: add support for special 0x8000 regulatory domain · 5d2214ac
      Luis R. Rodriguez 提交于
      Two users of ar9170 devices have now reported their cards
      have been programmed with a regulatory domain of 0x8000.
      This is not a valid regulatory domain as such these users were
      unable to use these devices. Since this doesn't seem to be
      a device EEPROM corruption we must treat it specially. It
      may have been possible the manufacturer intended to use 0x0
      as the regulatory domain and that would ultimately yield
      to US but since we cannot get confirmationf or this we
      default this special case to one of our world regulatory
      domains, specifically 0x64.
      
      Reported-by: DavidFreeman on #linux-wireless
      Reported-by: NJoerg Albert <jal2@gmx.de>
      Cc: Christian Lamparter <chunkeey@web.de>,
      Cc: Stephen Chen <stephen.chen@atheros.com>
      Cc: David Quan <david.quan@atheros.com>
      Cc: Tony Yang <tony.yang@atheros.com>
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5d2214ac
  3. 11 7月, 2009 1 次提交
  4. 04 6月, 2009 1 次提交
  5. 21 5月, 2009 1 次提交
    • L
      cfg80211: Process regulatory max bandwidth checks for HT40 · 038659e7
      Luis R. Rodriguez 提交于
      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: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      038659e7
  6. 23 4月, 2009 7 次提交
  7. 28 3月, 2009 1 次提交
  8. 17 3月, 2009 2 次提交
  9. 06 3月, 2009 1 次提交
    • J
      ath9k: Add data structure for supporting virtual radio/wiphy operation · bce048d7
      Jouni Malinen 提交于
      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: NJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      bce048d7
  10. 28 2月, 2009 6 次提交
  11. 14 2月, 2009 3 次提交
  12. 10 2月, 2009 4 次提交
  13. 30 1月, 2009 2 次提交
    • L
      ath9k: fix debug print on regd · 0c6666e4
      Luis R. Rodriguez 提交于
      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: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0c6666e4
    • L
      ath9k: simplify regulatory code · 5f8e077c
      Luis R. Rodriguez 提交于
      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: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5f8e077c
  14. 05 12月, 2008 3 次提交
  15. 07 8月, 2008 3 次提交