Checking whether a mutex is not locked directly before
mutex_lock() is called, doesn't make sense. The whole point of
mutex_lock() is to block, if the mutex is locked.
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>

Caused by the fact that physical control registers appear to have
only a width of 16 bit, 32-bit writes are not required.
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>

Signed-off-by: NDaniel Drake <dsd@gentoo.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Inspired by an e-mail by Stephen Hemminger I decided to remove all
unneeded packed attributes from the code where the member variables are
already aligned. This avoids horrible code being generated on some
architectures.
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>

Tested by Vincent TOUCHARD

zd1211 chip 0b05:170c v4802 high 00-11-d8 AL2230_RF pa0 g---
Signed-off-by: NDaniel Drake <dsd@gentoo.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Tested by Martin Dummer.

zd1211 chip 0b3b:5630 v4330 high 00-01-e3 RF2959_RF pa0 ---
Signed-off-by: NDaniel Drake <dsd@gentoo.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Caused by a documentation issue I mixed up fields of the zd_status
structure. This patch fixes it and improves also the average
computation, which is now using only measurements of packets sent
by the access point.
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>

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>

The Longshine device is a ZD1211B and has a AL2230 RF. I tested it
successfully with no encryption and WEP.
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>

Some devices identify themselves as a virtual USB CDROM drive. The virtual CD
includes the windows driver. We aren't interested in this, so we eject the
virtual CDROM and then the real wireless device appears.

Patch fixed over the earlier version to not leak cmd, thanks to Michael Buesch
for spotting that.
Signed-off-by: NDaniel Drake <dsd@gentoo.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

zd1211 chip 0586:3402 v4916 high 00-13-49 AL2230_RF pa0 ----

This device pops up after the virtual driver CD has been ejected.
Signed-off-by: NDaniel Drake <dsd@gentoo.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This is needed for my G220F, otherwise it fails to initialize after the
existing firmware upload routine.

The vendor driver actually does more than what I have done here: it
downloads the firmware + boot code, modifies it, and uploads it again
(really messy). I have not copied that part over, as my device can get
on its feet without it.
Signed-off-by: NDaniel Drake <dsd@gentoo.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Tested by Wonka on IRC.

zd1211 chip 157e:3204 v4810 high 00-11-e0 AL7230B_RF pa0 g---
Signed-off-by: NDaniel Drake <dsd@gentoo.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Tested by lyakh on IRC

zd1211 chip 1740:2000 v4721 high 00-02-6f AL7230B_RF pa0 g---
Signed-off-by: NDaniel Drake <dsd@gentoo.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch adds support for another Airoha RF which is present in some
ZD1211 adapters. This RF supports 802.11a as well as 802.11b/g, but 802.11a
connectivity is not yet supported by this driver.
Signed-off-by: NDaniel Drake <dsd@gentoo.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch synchronizes our code to some recent vendor driver modifications.
A new PHY layout is supported, some values are tweaked, and the AL2230 is now
programmed over a new interface which is many times faster.
Signed-off-by: NDaniel Drake <dsd@gentoo.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The vendor driver resets the IFS value every time the channel changes,
to this one.
Signed-off-by: NDaniel Drake <dsd@gentoo.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The vendor driver chooses this value based on an ifndef ASIC,
and ASIC is never defined.
Signed-off-by: NDaniel Drake <dsd@gentoo.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

I had problems with my AVM Fritz!Box access point. It appeared
that the AP deauthorized me and the softmac didn't reconnect me.
This patch handles the problem.
Signed-off-by: NUlrich Kunitz <kune@deine-taler.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Discovered a problem while accessing www.python.org on my PPC32.
The problem was pretty consistent for all sticks. The reason was
that while testing for the length info tag, I ignored the
endianess of the host system.

Please recognize that converting the constant to little endian, we
create faster code.
Signed-off-by: NUlrich Kunitz <kune@deine-taler.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This function is never called in interrupt context, and it doesn't
matter if it is called in IRQ context or not.
Signed-off-by: NDaniel Drake <dsd@gentoo.org>
Signed-off-by: NUlrich Kunitz <kune@deine-taler.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Apparently the ZD1211 doesn't mind, but the ZD1211B absolutely must be
told that encryption is happening in software.
Signed-off-by: NDaniel Drake <dsd@gentoo.org>
Signed-off-by: NUlrich Kunitz <kune@deine-taler.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We'll be needing these at some point...
Signed-off-by: NDaniel Drake <dsd@gentoo.org>
Signed-off-by: NUlrich Kunitz <kune@deine-taler.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There has been a problem in the radiotap header. Monitor mode
works now with tcpdump 3.94 + libpcap 0.9.4. ethereal 0.99.0 +
libpcap 0.9.4 is broken, because it doesn't find the right offset
for the IEEE 802.11 header.
Signed-off-by: NUlrich Kunitz <kune@deine-taler.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

wireless.h discourages using SIOCGIWNAME to publish the driver name
which the interface belongs to. Use SIOCGIWNICKN instead.
Signed-off-by: NDaniel Drake <dsd@gentoo.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Based on a patch by Matthieu CASTET.

zd1211 chip 079b:004a v4330 high 00-60-b3 AL2230_RF pa0 g--
zd1211b chip 079b:0062 v4810 high 00-60-b3 AL2230_RF pa0 g--
Signed-off-by: NDaniel Drake <dsd@gentoo.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We will reimplement halt-clearing later, when we have periodic
housekeeping routines in place. This will do as a temporary fix, the
EPIPE case has not yet been seen.
Signed-off-by: NDaniel Drake <dsd@gentoo.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This avoids some potential races.
Signed-off-by: NDaniel Drake <dsd@gentoo.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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>