1. 06 Oct, 2010 1 commit
  2. 25 Jan, 2010 2 commits
  3. 08 Sep, 2009 1 commit
  4. 28 Aug, 2009 1 commit
    • Gábor Stefanik's avatar
      b43: Fix and update LP-PHY code · 68ec5329
      Gábor Stefanik authored
      -Fix a few nasty typos (b43_phy_* operations instead of b43_radio_*)
       in the channel tune routines.
      -Fix some typos & spec errors found by MMIO tracing.
      -Optimize b43_phy_write & b43_phy_mask/set/maskset to use
       only the minimal number of MMIO accesses. (Write is possible
       using a single 32-bit MMIO write, while set/mask/maskset can
       be done in 3 16-bit MMIOs).
      -Set the default channel back to 1, as the bug forcing us to use
       channel 7 is now fixed.
      With this, the device comes up, scans, associates, transmits,
      receives, monitors and injects on all channels - in other words,
      it's fully functional. Sensitivity and TX power are still sub-optimal,
      due to the lack of calibration (that's next on my list).
      Signed-off-by: default avatarGábor Stefanik <netrolller.3d@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  5. 04 Aug, 2009 2 commits
    • Gábor Stefanik's avatar
      b43: implement baseband init for LP-PHY <= rev1 · 738f0f43
      Gábor Stefanik authored
      Implement baseband init for rev.0 and rev.1 LP PHYs. Convert boardflags_hi values to defines.
      Implement b43_phy_copy for easier copying between registers, as needed by LP-PHY init.
      Signed-off-by: default avatarGábor <Stefanik&lt;netrolller.3d@gmail.com>
      Cc: Michael Buesch<mb@bu3sch.de>
      Cc: Larry Finger<larry.finger@lwfinger.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Luis R. Rodriguez's avatar
      mac80211: redefine usage of the mac80211 workqueue · 42935eca
      Luis R. Rodriguez authored
      The mac80211 workqueue exists to enable mac80211 and drivers
      to queue their own work on a single threaded workqueue. mac80211
      takes care to flush the workqueue during suspend but we never
      really had requirements on drivers for how they should use
      the workqueue in consideration for suspend.
      We extend mac80211 to document how the mac80211 workqueue should
      be used, how it should not be used and finally move raw access to
      the workqueue to mac80211 only. Drivers and mac80211 use helpers
      to queue work onto the mac80211 workqueue:
        * ieee80211_queue_work()
        * ieee80211_queue_delayed_work()
      These helpers will now warn if mac80211 already completed its
      suspend cycle and someone is trying to queue work. mac80211
      flushes the mac80211 workqueue prior to suspend a few times,
      but we haven't taken the care to ensure drivers won't add more
      work after suspend. To help with this we add a warning when
      someone tries to add work and mac80211 already completed the
      suspend cycle.
      Drivers should ensure they cancel any work or delayed work
      in the mac80211 stop() callback.
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  6. 03 Jun, 2009 1 commit
    • Johannes Berg's avatar
      rfkill: rewrite · 19d337df
      Johannes Berg authored
      This patch completely rewrites the rfkill core to address
      the following deficiencies:
       * all rfkill drivers need to implement polling where necessary
         rather than having one central implementation
       * updating the rfkill state cannot be done from arbitrary
         contexts, forcing drivers to use schedule_work and requiring
         lots of code
       * rfkill drivers need to keep track of soft/hard blocked
         internally -- the core should do this
       * the rfkill API has many unexpected quirks, for example being
         asymmetric wrt. alloc/free and register/unregister
       * rfkill can call back into a driver from within a function the
         driver called -- this is prone to deadlocks and generally
         should be avoided
       * rfkill-input pointlessly is a separate module
       * drivers need to #ifdef rfkill functions (unless they want to
         depend on or select RFKILL) -- rfkill should provide inlines
         that do nothing if it isn't compiled in
       * the rfkill structure is not opaque -- drivers need to initialise
         it correctly (lots of sanity checking code required) -- instead
         force drivers to pass the right variables to rfkill_alloc()
       * the documentation is hard to read because it always assumes the
         reader is completely clueless and contains way TOO MANY CAPS
       * the rfkill code needlessly uses a lot of locks and atomic
         operations in locked sections
       * fix LED trigger to actually change the LED when the radio state
         changes -- this wasn't done before
      Tested-by: default avatarAlan Jenkins <alan-jenkins@tuffmail.co.uk>
      Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> [thinkpad]
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  7. 16 Apr, 2009 1 commit
  8. 19 Dec, 2008 2 commits
  9. 15 Sep, 2008 1 commit
  10. 08 Sep, 2008 1 commit
  11. 05 Sep, 2008 3 commits
  12. 29 Aug, 2008 2 commits
    • Michael Buesch's avatar
      b43: Rewrite TX power adjustment · 18c8adeb
      Michael Buesch authored
      This patch rewrites the TX power recalculation algorithms to scale better
      with changed enviromnent. If there's low
      TX traffic, the power will be checked against the desired values
      every 60 seconds.
      If there is high TX traffic, the check is redone every 2 seconds. This improves
      the reaction times a lot and confuses the rate control less.
      It will also reduce the time it initially takes to tune to a new TX power
      value. With the old algorithm it could take about 30 to 45 seconds to settle to
      a new power value. This will happen in about two to four seconds now.
      Signed-off-by: default avatarMichael Buesch <mb@bu3sch.de>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Michael Buesch's avatar
      b43: Implement dynamic PHY API · ef1a628d
      Michael Buesch authored
      This patch implements a dynamic "ops" based PHY API.
      This is needed in order to conveniently support future PHY types
      to avoid the "switch"-hell.
      This patch does not change any functionality. It just moves lots
      of code from one place to another and adjusts it for the changed
      data structures.
      Signed-off-by: default avatarMichael Buesch <mb@bu3sch.de>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>