1. 27 6月, 2008 3 次提交
  2. 17 6月, 2008 1 次提交
    • D
      wext: Emit event stream entries correctly when compat. · ccc58057
      David S. Miller 提交于
      Three major portions to this change:
      
      1) Add IW_EV_COMPAT_LCP_LEN, IW_EV_COMPAT_POINT_OFF,
         and IW_EV_COMPAT_POINT_LEN helper defines.
      
      2) Delete iw_stream_check_add_*(), they are unused.
      
      3) Add iw_request_info argument to iwe_stream_add_*(), and use it to
         size the event and pointer lengths correctly depending upon whether
         IW_REQUEST_FLAG_COMPAT is set or not.
      
      4) The mechanical transformations to the drivers and wireless stack
         bits to get the iw_request_info passed down into the routines
         modified in #3.  Also, explicit references to IW_EV_LCP_LEN are
         replaced with iwe_stream_lcp_len(info).
      
      With a lot of help and bug fixes from Masakazu Mokuno.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ccc58057
  3. 14 6月, 2008 1 次提交
  4. 10 6月, 2008 1 次提交
  5. 29 5月, 2008 1 次提交
  6. 21 5月, 2008 1 次提交
  7. 15 5月, 2008 1 次提交
    • B
      mac80211: use hardware flags for signal/noise units · 566bfe5a
      Bruno Randolf 提交于
      trying to clean up the signal/noise code. the previous code in mac80211 had
      confusing names for the related variables, did not have much definition of
      what units of signal and noise were provided and used implicit mechanisms from
      the wireless extensions.
      
      this patch introduces hardware capability flags to let the hardware specify
      clearly if it can provide signal and noise level values and which units it can
      provide. this also anticipates possible new units like RCPI in the future.
      
      for signal:
      
        IEEE80211_HW_SIGNAL_UNSPEC - unspecified, unknown, hw specific
        IEEE80211_HW_SIGNAL_DB     - dB difference to unspecified reference point
        IEEE80211_HW_SIGNAL_DBM    - dBm, difference to 1mW
      
      for noise we currently only have dBm:
      
        IEEE80211_HW_NOISE_DBM     - dBm, difference to 1mW
      
      if IEEE80211_HW_SIGNAL_UNSPEC or IEEE80211_HW_SIGNAL_DB is used the driver has
      to provide the maximum value (max_signal) it reports in order for applications
      to make sense of the signal values.
      
      i tried my best to find out for each driver what it can provide and update it
      but i'm not sure (?) for some of them and used the more conservative guess in
      doubt. this can be fixed easily after this patch has been merged by changing
      the hardware flags of the driver.
      
      DRIVER          SIGNAL    MAX	NOISE   QUAL
      -----------------------------------------------------------------
      adm8211         unspec(?) 100   n/a     missing
      at76_usb        unspec(?) (?)   unused  missing
      ath5k           dBm             dBm     percent rssi
      b43legacy       dBm             dBm     percent jssi(?)
      b43             dBm             dBm     percent jssi(?)
      iwl-3945        dBm             dBm     percent snr+more
      iwl-4965        dBm             dBm     percent snr+more
      p54             unspec    127   n/a     missing
      rt2x00          dBm	        n/a     percent rssi+tx/rx frame success
        rt2400        dBm             n/a
        rt2500pci     dBm             n/a
        rt2500usb     dBm             n/a
        rt61pci       dBm             n/a
        rt73usb       dBm             n/a
      rtl8180         unspec(?) 65    n/a     (?)
      rtl8187         unspec(?) 65    (?)     noise(?)
      zd1211          dB(?)     100   n/a     percent
      
      drivers/net/wireless/ath5k/base.c:      Changes-licensed-under: 3-Clause-BSD
      Signed-off-by: NBruno Randolf <br1@einfach.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      566bfe5a
  8. 17 4月, 2008 2 次提交
  9. 09 4月, 2008 3 次提交
    • J
      mac80211: rename files · 2c8dccc7
      Johannes Berg 提交于
      This patch renames all mac80211 files (except ieee80211_i.h) to get rid
      of the useless ieee80211_ prefix.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2c8dccc7
    • J
      mac80211: fix key vs. sta locking problems · 3b96766f
      Johannes Berg 提交于
      Up to now, key manipulation is supposed to run under RTNL to
      avoid concurrent manipulations and also allow the set_key()
      hardware callback to sleep. This is not feasible because STA
      structs are rcu-protected and thus a lot of operations there
      cannot take the RTNL. Also, key references are rcu-protected
      so we cannot do things atomically.
      
      This patch changes key locking completely:
       * key operations are now atomic
       * hardware crypto offload is enabled and disabled from
         a workqueue, due to that key freeing is also delayed
       * debugfs code is also run from a workqueue
       * keys reference STAs (and vice versa!) so during STA
         unlink the STAs key reference is removed but not the
         keys STA reference, to avoid races key todo work is
         run before STA destruction.
       * fewer STA operations now need the RTNL which was
         required due to key operations
      
      This fixes the locking problems lockdep pointed out and also
      makes things more light-weight because the rtnl isn't required
      as much.
      
      Note that the key todo lock/key mutex are global locks, this
      is not required, of course, they could be per-hardware instead.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3b96766f
    • J
      mac80211: fix ieee80211_ioctl_giwrate · 380a942b
      Johannes Berg 提交于
      The ieee80211_ioctl_giwrate() ioctl handler doesn't rcu_read_lock()
      its access to the sta table, fix it.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      380a942b
  10. 28 3月, 2008 1 次提交
  11. 26 3月, 2008 2 次提交
  12. 07 3月, 2008 3 次提交
  13. 01 3月, 2008 2 次提交
    • J
      mac80211: split ieee80211_key_alloc/free · db4d1169
      Johannes Berg 提交于
      In order to RCU-ify sta_info, we need to be able to allocate
      a key without linking it to an sdata/sta structure (because
      allocation cannot be done in an rcu critical section). This
      patch splits up ieee80211_key_alloc() and updates all users
      appropriately.
      
      While at it, this patch fixes a number of race conditions
      such as finally making key replacement atomic, unfortunately
      at the expense of more complex code.
      
      Note that this patch documents /existing/ bugs with sta info
      and key interaction, there is currently a race condition
      when a sta info is freed without holding the RTNL. This will
      finally be fixed by a followup patch.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      db4d1169
    • 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
  14. 29 1月, 2008 7 次提交
  15. 09 1月, 2008 1 次提交
  16. 11 11月, 2007 2 次提交
  17. 18 10月, 2007 1 次提交
  18. 17 10月, 2007 2 次提交
  19. 11 10月, 2007 5 次提交