1. 21 May, 2008 5 commits
  2. 14 May, 2008 4 commits
    • Harvey Harrison's avatar
      b43: use the bitrev helpers rather than rolling a private one · 6dcdc19e
      Harvey Harrison authored
      The 4-bit reversal flip_4bit is replaced with the bitrev helper
      bitrev8 and a 4-bit shift.  The B43_WARN is moved to the location
      where a register is read from for checking there.  The other caller
      explicitly passes an array index which is guaranteed to be within range
      and so a B43_WARN is not added there.
      Signed-off-by: default avatarHarvey Harrison <harvey.harrison@gmail.com>
      Reviewed-by: default avatarMichael Buesch <mb@bu3sch.de>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Huang Weiyi's avatar
      b43: nphy.c remove duplicated include · 7a1d6523
      Huang Weiyi authored
      Remove duplicated include <linux/delay.h> in
      Signed-off-by: default avatarHuang Weiyi <weiyi.huang@gmail.com>
      Signed-off-by: default avatarMichael Buesch <mb@bu3sch.de>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Bruno Randolf's avatar
      mac80211: use hardware flags for signal/noise units · 566bfe5a
      Bruno Randolf authored
      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: default avatarBruno Randolf <br1@einfach.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Harvey Harrison's avatar
      b43: replace limit_value macro with clamp_val · cdbf0846
      Harvey Harrison authored
      kernel-provided clamp_val is identical, delete the private limit_value helper.
      Signed-off-by: default avatarHarvey Harrison <harvey.harrison@gmail.com>
      Cc: Michael Buesch <mb@bu3sch.de>
      Cc: "John W. Linville" <linville@tuxdriver.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  3. 07 May, 2008 6 commits
  4. 01 May, 2008 1 commit
  5. 30 Apr, 2008 1 commit
  6. 29 Apr, 2008 1 commit
  7. 23 Apr, 2008 4 commits
  8. 19 Apr, 2008 1 commit
    • Rafael J. Wysocki's avatar
      PM: Remove destroy_suspended_device() · b844eba2
      Rafael J. Wysocki authored
      After 2.6.24 there was a plan to make the PM core acquire all device
      semaphores during a suspend/hibernation to protect itself from
      concurrent operations involving device objects.  That proved to be
      too heavy-handed and we found a better way to achieve the goal, but
      before it happened, we had introduced the functions
      device_pm_schedule_removal() and destroy_suspended_device() to allow
      drivers to "safely" destroy a suspended device and we had adapted some
      drivers to use them.  Now that these functions are no longer necessary,
      it seems reasonable to remove them and modify their users to use the
      normal device unregistration instead.
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: default avatarPavel Machek <pavel@ucw.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
  9. 16 Apr, 2008 1 commit
    • Michael Buesch's avatar
      b43: Add fastpath to b43_mac_suspend() · ba380013
      Michael Buesch authored
      This adds a fastpath for the common workloads to the
      MAC suspend flushing.
      In common workloads the FIFO flush will take between 100 and
      200 microseconds. So we want to avoid calling msleep() in the
      common case, as it will waste over 800 microseconds + scheduler
      This fastpath will hit in workloads where only small chunks
      of data are transmitted (downloading a file) or when a TX rate bigger
      or equal to 24MBit/s is used when transmitting lots of stuff (iperf).
      So in the commonly used workloads it will basically always hit.
      In case the fastpath is not hit, there's no real performance or latency
      disadvantage from that.
      And yes, I measured this. So this is not one of these
      bad Programmer Likeliness Assumptions that are always wrong. ;)
      Signed-off-by: default avatarMichael Buesch <mb@bu3sch.de>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  10. 15 Apr, 2008 1 commit
    • Michael Buesch's avatar
      ssb: Fix usage of struct device used for DMAing · 4ac58469
      Michael Buesch authored
      This fixes DMA on architectures where DMA is nontrivial, like PPC64.
      We must use the host-device's (PCI) struct device for any DMA
      operation instead of the SSB device. For this we add a new
      struct device pointer to the SSB device structure that will always
      point to the right device for DMAing.
      Without this patch b43 and b44 drivers won't work on complex-DMA
      architectures, that for example need dev->archdata for DMA operations.
      Signed-off-by: default avatarMichael Buesch <mb@bu3sch.de>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  11. 08 Apr, 2008 9 commits
  12. 01 Apr, 2008 2 commits
  13. 25 Mar, 2008 1 commit
  14. 24 Mar, 2008 2 commits
  15. 13 Mar, 2008 1 commit