Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 05 2月, 2011 6 次提交
  3. 17 6月, 2010 2 次提交
  5. 03 6月, 2010 1 次提交
  7. 28 10月, 2009 1 次提交
    • B
      zd1211rw: Fix TX status reporting in order to have proper rate control · 7f4013f0
      由 Benoit PAPILLAULT 提交于 
      First, we reduce the number of hardware retries to 0 (ie 2 real retries
for each rate). Next, when we report the retries to mac80211, we always
report a retry count of 1 (it seems to be 2 in fact, but using 2 seems
to lead to wrong performance for some reason). We use a state machine to
determine the real fate of a packet based on the 802.11 ACK and what the
Zydas hardware is saying when a real retry occurs. The real retry rates
are encoded in a static array. It has been tested with both zd1211 and
zd1211b hardware. Of course, since the Zydas hardware is not reporting
retries accurately, we are just doing our best in order to get the best
performance (ie higher throughput).
Signed-off-by: NBenoit PAPILLAULT <benoit.papillault@free.fr>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7f4013f0
  9. 21 5月, 2009 1 次提交
  11. 16 9月, 2008 1 次提交
  13. 22 5月, 2008 1 次提交
  15. 07 3月, 2008 1 次提交
  17. 01 3月, 2008 1 次提交
    • J
      cfg80211 API for channels/bitrates, mac80211 and driver conversion · 8318d78a
      由 Johannes Berg 提交于 
      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: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8318d78a
  19. 29 1月, 2008 2 次提交
  21. 11 10月, 2007 1 次提交
    • U
      [PATCH] zd1211rw: consistent handling of ZD1211 specific rates · 64f222cc
      由 Ulrich Kunitz 提交于 
      As pointed out by Daniel Drake, the zd1211rw driver used several
different rate values and names throughout the driver. He has
written a patch to change it and tweaked it after some pretty wild
ideas from my side. But the discussion helped me to understand the
problem better and I think I have nailed it down with this patch.

A zd-rate will consist from now on of a four-bit "pure" rate value
and a modulation type flag as used in the ZD1211 control set used
for packet transmission. This is consistent with the usage in the
zd_rates table. If possible these zd-rates should be used in the
code.
Signed-off-by: NUlrich Kunitz <kune@deine-taler.de>
Signed-off-by: NDaniel Drake <dsd@gentoo.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      64f222cc
  23. 11 7月, 2007 1 次提交
    • D
      [PATCH] zd1211rw: Defer firmware load until first ifup · 74553aed
      由 Daniel Drake 提交于 
      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
loaded.

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
on.

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: NDaniel Drake <dsd@gentoo.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      74553aed
  25. 20 12月, 2006 1 次提交
  27. 06 12月, 2006 2 次提交
  29. 02 12月, 2006 3 次提交
  31. 29 11月, 2006 1 次提交
  33. 22 11月, 2006 1 次提交
  35. 26 9月, 2006 1 次提交
  37. 12 9月, 2006 2 次提交
  39. 15 8月, 2006 1 次提交
    • U
      [PATCH] zd1211rw: cleanups · c48cf125
      由 Ulrich Kunitz 提交于 
      Add static to 2 internal functions. Thanks goes to Adrian Bunk, who found that.

Also made some modifications to the clear functions:

After a discussion on the mailing list, I implemented this code to
have on the one hand sufficient test in debug mode, but on the
other hand reduce the overhead for structure clearing to a
minimum.

A new macro ZD_MEMCLEAR is introduced, which produces code if
DEBUG is set. Locks are not set anymore for structure clearing,
but in debug mode, there is a verification, that the locks have
not been set.

Finally, removed a misleading comment regarding locking in the disconnect
path.
Signed-off-by: NUlrich Kunitz <kune@deine-taler.de>
Signed-off-by: NDaniel Drake <dsd@gentoo.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c48cf125
  41. 06 7月, 2006 1 次提交
    • D
      [PATCH] ZyDAS ZD1211 USB-WLAN driver · e85d0918
      由 Daniel Drake 提交于 
      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: NDaniel Drake <dsd@gentoo.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e85d0918