1. 23 5月, 2009 1 次提交
  2. 21 5月, 2009 1 次提交
  3. 14 5月, 2009 1 次提交
    • J
      cfg80211: implement wext key handling · 08645126
      Johannes Berg 提交于
      Move key handling wireless extension ioctls from mac80211 to cfg80211
      so that all drivers that implement the cfg80211 operations get wext
      compatibility.
      
      Note that this drops the SIOCGIWENCODE ioctl support for getting
      IW_ENCODE_RESTRICTED/IW_ENCODE_OPEN. This means that iwconfig will
      no longer report "Security mode:open" or "Security mode:restricted"
      for mac80211. However, what we displayed there (the authentication
      algo used) was actually wrong -- linux/wireless.h states that this
      setting is meant to differentiate between "Refuse non-encoded packets"
      and "Accept non-encoded packets".
      
      (Combined with "cfg80211: fix a couple of bugs with key ioctls". -- JWL)
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      08645126
  4. 23 4月, 2009 1 次提交
    • J
      cfg80211: clean up includes · d3236553
      Johannes Berg 提交于
      Trying to separate header files into net/wireless.h and
      net/cfg80211.h has been a source of confusion. Remove
      net/wireless.h (because there also is the linux/wireless.h)
      and subsume everything into net/cfg80211.h -- except the
      definitions for regulatory structures which get moved to
      a new header net/regulatory.h.
      
      The "new" net/cfg80211.h is now divided into sections.
      
      There are no real changes in this patch but code shuffling
      and some very minor documentation fixes.
      
      I have also, to make things reflect reality, put in a
      copyright line for Luis to net/regulatory.h since that
      is probably exclusively written by him but was formerly
      in a file that only had my copyright line.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Cc: Luis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      d3236553
  5. 30 1月, 2009 1 次提交
  6. 11 11月, 2008 1 次提交
  7. 28 3月, 2008 1 次提交
  8. 26 3月, 2008 1 次提交
  9. 01 3月, 2008 3 次提交
    • I
      wireless: Fix WARN_ON() with ieee802.11b · 406f2388
      Ivo van Doorn 提交于
      When the driver registers a IEEE80211_BAND_2GHZ band,
      it can either be 802.11b or 802.11g. But when 802.11b rates
      are registered "want" will be 3 (since 4 rates are being registered,
      and each of those 4 rates will decrease "want").
      Since this is a correct situation, there is no need to trigger
      a WARN_ON() for this.
      Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      406f2388
    • J
      wireless: fix ERP rate flags · aac09fbf
      Johannes Berg 提交于
      In the rate API patch I accidentally reverted the test for
      ERP rates, this fixes it. All rates except 1, 2, 5.5 and 11
      MBit are ERP rates, not those.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      aac09fbf
    • J
      cfg80211 API for channels/bitrates, mac80211 and driver conversion · 8318d78a
      Johannes Berg 提交于
      This patch creates new cfg80211 wiphy API for channel and bitrate
      registration and converts mac80211 and drivers to the new API. The
      old mac80211 API is completely ripped out. All drivers (except ath5k)
      are updated to the new API, in many cases I expect that optimisations
      can be done.
      
      Along with the regulatory code I've also ripped out the
      IEEE80211_HW_DEFAULT_REG_DOMAIN_CONFIGURED flag, I believe it to be
      unnecessary if the hardware simply gives us whatever channels it wants
      to support and we then enable/disable them as required, which is pretty
      much required for travelling.
      
      Additionally, the patch adds proper "basic" rate handling for STA
      mode interface, AP mode interface will have to have new API added
      to allow userspace to set the basic rate set, currently it'll be
      empty... However, the basic rate handling will need to be moved to
      the BSS conf stuff.
      
      I do expect there to be bugs in this, especially wrt. transmit
      power handling where I'm basically clueless about how it should work.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8318d78a