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>
Tested by Zen Kato
zd1211b chip 0411:00da v4810 high 00-16-01 AL2230S_RF pa0 g--N-
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Tested by Guy Gallagher
zd1211 chip 0586:3407 v4721 high 00-13-49 AL2230_RF pa0 g---
FCC ID SI5WUB200Z
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Tested by davo on IRC
zd1211b chip 0586:3413 v4810 full 00-13-49 AL7230B_RF pa0 -----
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is another "driverless" device which first presents itself as a USB
CDROM drive. A separate patch has been submitted to make usb-storage
ignore that device, so that zd1211rw can eject it.
zd1211 chip 0df6:9075 v4916 full 00-0c-f6 AL2230_RF pa0 ----
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Alan Tam <Tam at SiuLung dot com> asked for inclusion of this
device into the tree.
zd1211b chip 0053:5301 v4810 high 00-90-cc AL2230_RF pa0 ---N
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>
Tested by Christoph Sager and Tomas Klas
zd1211b chip 0586:3412 v4810 high 00-13-49 AL7230B_RF pa0 g----
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Tested by TiCPU on irc
zd1211 chip 13b1:001e v4802 high 00-14-bf AL2230_RF pa0 g---
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ASUS A9Rp
Tested by Serge
zd1211b chip 0b05:171b v4802 high 00-17-31 AL2230_RF pa0 g--
ZyXEL G-202
Tested by Marcus D. Hanwell
zd1211b chip 0586:3410 v4810 high 00-13-49 AL2230_RF pa0 g---
US Robotics USR805423
Tested by Pascal S. de Kloe
FCC ID: RAXWN4501H
zd1211b chip 0baf:0121 v4810 high 00-14-c1 AL2230_RF pa0 g--N
Julien Pinon reports this also comes in AL2230S form
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>
USRobotics Wireless Adapter (Model 5423) works well with current
zd1211rw driver also (i have tested 2.6.18, 2.6.20 and 2.6.21-rc7).
It just needs its ID added to the list of devices.
Signed-off-by: S.Çağlar Onur <caglar@pardus.org.tr>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Added update of network device error statistics.
Based on earlier work by Maxime Austruy.
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 resets the device in the probe call. It does work with
2.6.19.2 including the softmac patches. It might fix the
reboot/reset problems a lot of people reported.
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>
usb_init should call destroy_workqueue when usb_register fails.
Signed-off-by: Maxime Austruy <maxime@tralhalla.org>
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>
Tested by Marijn Schouten
zd1211b chip 0586:340f v4810 high 00-13-49 AL2230_RF pa0 g---
FCC ID: I88G220V2
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Tested by Henrik Hjelte
zd1211b chip 13b1:0024 v4802 high 00-14-bf AL2230_RF pa0 ----
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>
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: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The driver called ieee80211_rx in hardware interrupt context. This has
been against the intention of the ieee80211_rx function. It caused a bug
in the crypto routines used by WPA. This patch calls ieee80211_rx in a
tasklet.
Signed-off-by: Ulrich Kunitz <kune@deine-taler.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There are a high number of split USB transactions, which contain
only one packet but have a length info field. This patch optimizes
this code by stopping parsing the length info structure if a zero
length field is encountered.
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>
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: Ulrich Kunitz <kune@deine-taler.de>
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
zd1211b chip 050d:705c v4810 high 00-17-3f AL2230_RF pa0 g--N
Tested by Bryan Barnard
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
zd1211 chip 14ea:ab13 v4330 high 00-90-cc AL2230_RF pa0 g---
Tested by Tetsuya Yatagai.
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Tested by Newsome on IRC
zd1211 chip 0586:3401 v4330 high 00-13-49 AL2230_RF pa0 g---
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch fixes the bug as reported in the kernel bug tracker
under the id 7244. The bug was simply that the interrupt lock has
been locked outside an interrupt without blocking the interrupt.
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>
Maintain a per-CPU global "struct pt_regs *" variable which can be used instead
of passing regs around manually through all ~1800 interrupt handlers in the
Linux kernel.
The regs pointer is used in few places, but it potentially costs both stack
space and code to pass it around. On the FRV arch, removing the regs parameter
from all the genirq function results in a 20% speed up of the IRQ exit path
(ie: from leaving timer_interrupt() to leaving do_IRQ()).
Where appropriate, an arch may override the generic storage facility and do
something different with the variable. On FRV, for instance, the address is
maintained in GR28 at all times inside the kernel as part of general exception
handling.
Having looked over the code, it appears that the parameter may be handed down
through up to twenty or so layers of functions. Consider a USB character
device attached to a USB hub, attached to a USB controller that posts its
interrupts through a cascaded auxiliary interrupt controller. A character
device driver may want to pass regs to the sysrq handler through the input
layer which adds another few layers of parameter passing.
I've build this code with allyesconfig for x86_64 and i386. I've runtested the
main part of the code on FRV and i386, though I can't test most of the drivers.
I've also done partial conversion for powerpc and MIPS - these at least compile
with minimal configurations.
This will affect all archs. Mostly the changes should be relatively easy.
Take do_IRQ(), store the regs pointer at the beginning, saving the old one:
struct pt_regs *old_regs = set_irq_regs(regs);
And put the old one back at the end:
set_irq_regs(old_regs);
Don't pass regs through to generic_handle_irq() or __do_IRQ().
In timer_interrupt(), this sort of change will be necessary:
- update_process_times(user_mode(regs));
- profile_tick(CPU_PROFILING, regs);
+ update_process_times(user_mode(get_irq_regs()));
+ profile_tick(CPU_PROFILING);
I'd like to move update_process_times()'s use of get_irq_regs() into itself,
except that i386, alone of the archs, uses something other than user_mode().
Some notes on the interrupt handling in the drivers:
(*) input_dev() is now gone entirely. The regs pointer is no longer stored in
the input_dev struct.
(*) finish_unlinks() in drivers/usb/host/ohci-q.c needs checking. It does
something different depending on whether it's been supplied with a regs
pointer or not.
(*) Various IRQ handler function pointers have been moved to type
irq_handler_t.
Signed-Off-By: David Howells <dhowells@redhat.com>
(cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit)
For housekeeping and watchdog tasks a workqueue is created. The
central workqueue is not used to prevent crashes creates by bugs.
It might be changed, when the housekeeping is stabilized.
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>
Tested by Vincent TOUCHARD
zd1211 chip 0b05:170c v4802 high 00-11-d8 AL2230_RF pa0 g---
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Tested by Martin Dummer.
zd1211 chip 0b3b:5630 v4330 high 00-01-e3 RF2959_RF pa0 ---
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>
The Longshine device is a ZD1211B and has a AL2230 RF. I tested it
successfully with no encryption and WEP.
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>
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: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John 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: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John 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: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John 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: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John 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: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John 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: Ulrich Kunitz <kune@deine-taler.de>
Signed-off-by: John 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: Daniel Drake <dsd@gentoo.org>
Signed-off-by: Ulrich Kunitz <kune@deine-taler.de>
Signed-off-by: John 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: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John 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: Daniel Drake <dsd@gentoo.org>
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>
Linus Torvalds