An error occurred fetching the project authors.
  1. 10 Apr, 2007 2 commits
  2. 05 Feb, 2007 2 commits
    • Daniel Drake's avatar
      [PATCH] zd1211rw: Remove addressing abstraction · 0ce34bc8
      Daniel Drake authored
      Instead of passing our own custom 32-bit addresses around and
      translating them, this patch makes all our register address constants
      absolute and removes the translation.
      
      There are two ugly parts:
       - fw_reg_addr() is needed to compute addresses of firmware registers, as this
         is dynamic based upon firmware
       - inc_addr() needs a small hack to handle byte vs word addressing
      
      However, both of those are only small, and we don't use fw_regs a whole
      lot anyway.
      
      The bonuses here include simplicity and improved driver readability. Also, the
      fact that registers are now referenced by 16-bit absolute addresses (as
      opposed to 32-bit pseudo addresses) means that over 2kb compiled code size has
      been shaved off.
      
      Includes some touchups and sparse fixes from Ulrich Kunitz.
      Signed-off-by: default avatarDaniel Drake <dsd@gentoo.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      0ce34bc8
    • Daniel Drake's avatar
      [PATCH] zd1211rw: Consistency for address space constants · ee302767
      Daniel Drake authored
      The zd1211rw address space has confused me once too many times. This
      patch introduces the following naming notation:
      
      Memory space is split into segments (cr, fw, eeprom) and segments may
      contain components (e.g. boot code inside eeprom). These names are
      arbitrary and only for the description below:
      
      x_START: Absolute address of segment start
      (previously these were named such as CR_BASE_OFFSET, but they weren't
      really offsets unless you were considering them as an offset to 0)
      
      x_LEN: Segment length
      
      x_y_LEN: Length of component y of segment x
      
      x_y_OFFSET: Relative address of component y into segment x. The absolute
      address for this component is (x_START + x_y_OFFSET)
      
      I also renamed EEPROM registers to EEPROM data. These 'registers' can't
      be written to using standard I/O and really represent predefined data
      from the vendor.
      Signed-off-by: default avatarDaniel Drake <dsd@gentoo.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      ee302767
  3. 06 Dec, 2006 1 commit
  4. 02 Dec, 2006 2 commits
    • Daniel Drake's avatar
      [PATCH] zd1211rw: Use softmac ERP handling functionality · b1382ede
      Daniel Drake authored
      This adds zd1211rw driver support for the softmac functionality I
      added a while back. We now obey changes in basic rates, use short
      preamble if it is available (but long if the AP says it's not),
      and send self-CTS in the proper situations.
      
      Locking fixed and improved by Ulrich Kunitz.
      Signed-off-by: default avatarDaniel Drake <dsd@gentoo.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      b1382ede
    • Ulrich Kunitz's avatar
      [PATCH] zd1211rw: cleanups · 741fec53
      Ulrich Kunitz authored
      Bit-field constants in zd_chip.h are now defined using a shift expression.
      The value 0x08 is now (1 << 3). The fix is intended to improve readability.
      
      Remove misleading comment in zd_mac.c: The function already returns -EPERM
      in managed mode (IW_MODE_INFRA).
      
      Remove unused code in zd_mac.c: The unused code intended for debugging
      rx_status values is no longer useful.
      
      Added dump_stack() to ZD_ASSERT macro: Output of the stack helps to debug
      assertions. Keep in mind that the ZD_ASSERT() macro only results in code,
      if DEBUG is defined.
      
      Improved comments for filter_rx()
      
      zd_usb.c: Added driver name to module init and exit functions
      Signed-off-by: default avatarUlrich Kunitz <kune@deine-taler.de>
      Signed-off-by: default avatarDaniel Drake <dsd@gentoo.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      741fec53
  5. 25 Sep, 2006 1 commit
  6. 14 Aug, 2006 4 commits
  7. 02 Aug, 2006 2 commits
  8. 05 Jul, 2006 1 commit
    • Daniel Drake's avatar
      [PATCH] ZyDAS ZD1211 USB-WLAN driver · e85d0918
      Daniel Drake authored
      There are 60+ USB wifi adapters available on the market based on the ZyDAS
      ZD1211 chip.
      
      Unlike the predecessor (ZD1201), ZD1211 does not have a hardware MAC, so most
      data operations are coordinated by the device driver. The ZD1211 chip sits
      alongside an RF transceiver which is also controlled by the driver. Our driver
      currently supports 2 RF types, we know of one other available in a few marketed
      products which we will be supporting soon.
      
      Our driver also supports the newer revision of ZD1211, called ZD1211B. The
      initialization and RF operations are slightly different for the new revision,
      but the main difference is 802.11e support. Our driver does not support the
      QoS features yet, but we think we know how to use them.
      
      This driver is based on ZyDAS's own GPL driver available from www.zydas.com.tw.
      ZyDAS engineers have been responsive and supportive of our efforts, so thumbs
      up to them. Additionally, the firmware is redistributable and they have
      provided device specs.
      
      This driver has been written primarily by Ulrich Kunitz and myself. Graham
      Gower, Greg KH, Remco and Bryan Rittmeyer have also contributed. The
      developers of ieee80211 and softmac have made our lives so much easier- thanks!
      
      We maintain a small info-page: http://zd1211.ath.cx/wiki/DriverRewrite
      
      If there is enough time for review, we would like to aim for inclusion in
      2.6.18. The driver works nicely as a STA, and can connect to both open and
      encrypted networks (we are using software-based encryption for now). We will
      work towards supporting more advanced features in the future (ad-hoc, master
      mode, 802.11a, ...).
      Signed-off-by: default avatarDaniel Drake <dsd@gentoo.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      e85d0918