1. 09 Jun, 2008 1 commit
  2. 21 May, 2008 1 commit
  3. 06 Mar, 2008 1 commit
  4. 29 Feb, 2008 2 commits
    • Michael Buesch's avatar
      zd1211rw: Fix beacon filter flags thinko · 2c1a1b12
      Michael Buesch authored
      We must not clear the FIF_BCN_PRBRESP_PROMISC bit in the
      new_flags. The zd-driver does support sending beacons and
      probe responses to the host. What the flag does is say "Send me
      all beacons and probe responses". And we actually do that. We always
      do that, so we ignore the case when the bit is disabled. But that is
      fine. But we must not clear the flag, as that tells mac80211 that
      we do not support passing beacons and probe responses to the stack.
      And that's not true.
      Signed-off-by: default avatarMichael Buesch <mb@bu3sch.de>
      Acked-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Johannes Berg's avatar
      cfg80211 API for channels/bitrates, mac80211 and driver conversion · 8318d78a
      Johannes Berg authored
      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: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  5. 20 Feb, 2008 1 commit
  6. 28 Jan, 2008 5 commits
  7. 17 Dec, 2007 1 commit
    • Ulrich Kunitz's avatar
      zd1211rw: Fix alignment problems · 93137943
      Ulrich Kunitz authored
      Shaddy Baddah found an alignment problem with zd1211rw driver at
      2007-11-19. This patch fixes it, it is based on the patch proposed by
      Herbert Xu. The alignment 4 has been the agreed value on the
      linux-wireless mailing list.
      Notify that the problem does only affect the old zd1211rw softmac
      driver and not the zd1211rw-mac80211 driver. Daniel Drake has
      already provided a patch for the replacement of the softmac
      driver, which this patch will break.
      Signed-off-by: default avatarUlrich Kunitz <kune@deine-taler.de>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  8. 10 Oct, 2007 4 commits
  9. 06 Aug, 2007 1 commit
  10. 10 Jul, 2007 2 commits
    • Daniel Drake's avatar
      [PATCH] zd1211rw: Defer firmware load until first ifup · 74553aed
      Daniel Drake authored
      While playing with the firmware a while back, I discovered a way to
      access the device's entire address space before the firmware has been
      Previously we were loading the firmware early on (during probe) so that
      we could read the MAC address from the EEPROM and register a netdevice.
      Now that we can read the EEPROM without having firmware, we can defer
      firmware loading until later while still reading the MAC address early
      This has the advantage that zd1211rw can now be built into the kernel --
      previously if this was the case, zd1211rw would be loaded before the
      filesystem is available and firmware loading would fail.
      Firmware load and other device initialization operations now happen the
      first time the interface is brought up.
      Some architectural changes were needed: handling of the is_zd1211b flag
      was moved into the zd_usb structure, MAC address handling was obviously
      changed, and a preinit_hw stage was added (the order is now: init,
      preinit_hw, init_hw).
      Signed-off-by: default avatarDaniel Drake <dsd@gentoo.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Daniel Drake's avatar
      [PATCH] zd1211rw: Allow channels 1-11 for unrecognised regulatory domains · 86d95c21
      Daniel Drake authored
      Zen Kato's device has a regulatory domain value of 0x49, which is not an
      IEEE 802.11 code and is not even identified in the vendor driver.
      Recent versions of the vendor driver don't even look at the regdomain
      value any more, and just allow channels 1-11 everywhere. This patch
      brings us more in line with that behaviour, by allowing channels 1-11
      for regdomains which we don't know about.
      Signed-off-by: default avatarDaniel Drake <dsd@gentoo.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  11. 28 Apr, 2007 2 commits
  12. 07 Feb, 2007 3 commits
  13. 19 Dec, 2006 1 commit
  14. 07 Dec, 2006 1 commit
  15. 05 Dec, 2006 4 commits
  16. 01 Dec, 2006 4 commits
  17. 28 Nov, 2006 1 commit
  18. 22 Nov, 2006 1 commit
  19. 17 Oct, 2006 1 commit
  20. 25 Sep, 2006 1 commit
  21. 11 Sep, 2006 2 commits