Trial and error reveals that CR_ZD1211B_TX_PWR_CTL* do not affect the
transmission power. Instead these registers seem to control the contention
windows limits for different QoS access categories.
Signed-off-by: Javier Cardona <javier@cozybit.com>
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This seems to be working smoothly now. Let's not hold back the mac80211
transition any further. This patch ports the existing driver from softmac
to mac80211.
Many thanks to everyone who helped out with the porting efforts.
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The kernel now provides a generic hexdump implementation should we need
it again, so we can remove it from zd1211rw. After removing that, only
one single-user function is left in zd_util. Move that to zd_mac and
remove zd_util.
Signed-off-by: Ulrich Kunitz <kune@deine-taler.de>
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
No need to initialize to NULL when variable is never used before
it's assigned the return value of a kmalloc() call.
Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
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: Ulrich Kunitz <kune@deine-taler.de>
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
While developing the driver we added a lot of debug messages for
setting hardware registers. These messages make the reading of the
log files difficult and are of no use anymore. This patch removes
those messages in zd_chip.c.
Signed-off-by: Ulrich Kunitz <kune@deine-taler.de>
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The vendor driver code suggests that CR47 patching happens on every channel
change for every RF (depending on bit 8 in POD).
Due to a bug in their driver (upper bits of RF_Mode get zeroed out, then
are examined for 1s when setting some other flags), this isn't actually
what happens, and their generic CCK patching routine never takes effect.
Some of their RF configurations do include explicit (duplicated) code
for CR47 patching though. This patch makes zd1211rw match that
behaviour.
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
These changes are needed for UW2453 RF support:
Add pointer which RF drivers can use to store private RF data
Add exit hook so that RF drivers can free private data
Allow RF's to disable the generic TX power integration handling code
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This change allows RF drivers to provide their own 6M band edge patching
implementation, while providing a generic implementation shared by most
currently supported RF's.
The upcoming ZD1211B/AL7230B code will use this to define its own
patching function, which is different from the other RF configurations.
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The vendor driver only does the CR123 write for non-USB devices (which
don't exist on the consumer market)
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ZD1211 appears to be back in production: a number of new devices have
been appearing! Some of them are using new radios.
This patch adds support for the next generation AL2230 RF chip which has
been spotted in a few new devices.
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Michael Buesch commented that GFP_NOFS should not be used in a
network driver.
Signed-off-by: Ulrich Kunitz <kune@deine-taler.de>
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Due to conflicting/confusing defines in the vendor driver, we were
reading E2P_PHY_REG from the wrong location.
CR157 patching was slightly incorrect in that the vendor driver only
patches in an 8-bit value, whereas we were patching 24 bits.
Additionally, CR157 patching was happening on both zd1211 and zd1211b,
but this should only happen on zd1211.
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: Ulrich Kunitz <kune@deine-taler.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
zd1211rw currently detects AL2230S-based devices as AL2230, and hence
programs the RF incorrectly. Transmit silently fails on this
misconfiguration.
After this patch, AL2230S devices are rejected with an error message, to
avoid any confusion with an apparent driver bug.
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Robert P.J. Day's recent commit ("getting rid of all casts of
k[cmz]alloc() calls") introduced a sparse warning for zd1211rw,
related to our type-checking of addresses.
zd_chip.c:116:15: warning: implicit cast to nocast type
This patch readds the type cast, it is correct.
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Many of the registers written during ZD1211 HMAC initialization are
duplicated exactly for ZD1211B. Move the identical ones into a generic
part, and write the hardware-specific ones separately.
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Run this:
#!/bin/sh
for f in $(grep -Erl "\([^\)]*\) *k[cmz]alloc" *) ; do
echo "De-casting $f..."
perl -pi -e "s/ ?= ?\([^\)]*\) *(k[cmz]alloc) *\(/ = \1\(/" $f
done
And then go through and reinstate those cases where code is casting pointers
to non-pointers.
And then drop a few hunks which conflicted with outstanding work.
Cc: Russell King <rmk@arm.linux.org.uk>, Ian Molton <spyro@f2s.com>
Cc: Mikael Starvik <starvik@axis.com>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: Roman Zippel <zippel@linux-m68k.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Kyle McMartin <kyle@mcmartin.ca>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Greg KH <greg@kroah.com>
Cc: Jens Axboe <jens.axboe@oracle.com>
Cc: Paul Fulghum <paulkf@microgate.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Karsten Keil <kkeil@suse.de>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Jeff Garzik <jeff@garzik.org>
Cc: James Bottomley <James.Bottomley@steeleye.com>
Cc: Ian Kent <raven@themaw.net>
Cc: Steven French <sfrench@us.ibm.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Neil Brown <neilb@cse.unsw.edu.au>
Cc: Jaroslav Kysela <perex@suse.cz>
Cc: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Support for multicast adresses is implemented by supporting the
set_multicast_list() function of the network device. Address
filtering is supported by a group hash table in the device.
This is based on earlier work by Benoit Papillaut. Fixes multicast packet
reception and ipv6 connectivity:
http://bugzilla.kernel.org/show_bug.cgi?id=7424http://bugzilla.kernel.org/show_bug.cgi?id=7425
Signed-off-by: Ulrich Kunitz <kune@deine-taler.de>
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch includes a big cleanup of the existing unused LED code,
and adds support for controlling the LED.
The link LED will blink if the device is not associated. The LED
switches between 2 seconds on and 1 second off. If the device is
associated the LED is switched on.
The link LED also indicates packet TX. I do a little bit more led
resetting than the vendor driver, but the device works now as
expected for single LED and double LED devices.
Signed-off-by: Ulrich Kunitz <kune@deine-taler.de>
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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: Ulrich Kunitz <kune@deine-taler.de>
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John 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: Ulrich Kunitz <kune@deine-taler.de>
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John 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: Ulrich Kunitz <kune@deine-taler.de>
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John 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: Ulrich Kunitz <kune@deine-taler.de>
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John 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: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John 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: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The vendor driver resets the IFS value every time the channel changes,
to this one.
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The vendor driver chooses this value based on an ifndef ASIC,
and ASIC is never defined.
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John 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: Ulrich Kunitz <kune@deine-taler.de>
Signed-off-by: John 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: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Javier Cardona