1. 15 7月, 2008 5 次提交
  2. 09 7月, 2008 1 次提交
  3. 08 7月, 2008 5 次提交
  4. 03 7月, 2008 1 次提交
  5. 01 7月, 2008 4 次提交
  6. 27 6月, 2008 4 次提交
  7. 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
  8. 15 6月, 2008 2 次提交
  9. 10 6月, 2008 3 次提交
  10. 04 6月, 2008 2 次提交
  11. 29 5月, 2008 4 次提交
  12. 22 5月, 2008 2 次提交
  13. 21 5月, 2008 1 次提交
  14. 17 5月, 2008 1 次提交
  15. 15 5月, 2008 3 次提交
    • 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
    • J
      mac80211: proper STA info locking · 07346f81
      Johannes Berg 提交于
      As discussed earlier, we can unify locking in struct sta_info
      and use just a single spinlock protecting all members of the
      structure that need protection. Many don't, but one of the
      especially bad ones is the 'flags' member that can currently
      be clobbered when RX and TX is being processed on different
      CPUs at the same time.
      
      Because having four spinlocks for different, mostly exclusive
      parts of a single structure is overkill, this patch also kills
      the ampdu and mesh plink spinlocks and uses just a single one
      for everything. Because none of the spinlocks are nested, this
      is safe.
      
      It remains to be seen whether or not we should make the sta
      flags use atomic bit operations instead, for now though this
      is a safe thing and using atomic operations instead will be
      very simple using the new static inline functions this patch
      introduces for accessing sta->flags.
      
      Since spin_lock_bh() is used with this lock, there shouldn't
      be any contention even if aggregation is enabled at around the
      same time as both requires frame transmission/reception which
      is in a bh context.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Cc: Tomas Winkler <tomasw@gmail.com>
      Cc: Ron Rindjunsky <ron.rindjunsky@intel.com>
      Cc: Luis Carlos Cobo <luisca@cozybit.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      07346f81
    • J
      mac80211: require four hardware queues for QoS/HT · 3434fbd3
      Johannes Berg 提交于
      This patch makes mac80211 only announce QoS/HT support when
      the underlying hardware has four (or more) queues.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Cc: Ron Rindjunksi <ron.rindjunksi@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3434fbd3
  16. 13 5月, 2008 1 次提交