The previously unused CR_CAM_MODE register is set to MODE_AP_WDS. This makes the
driver ack mesh (WDS) frames. It does not affect Infra functionality of the
driver.
Previously missing beaconing support has been added. This might also help
implement a currently missing ah-hoc mode.
Support for interrupts from the device have been added, but we are not handling
most of them.
Mesh interfaces are considered associated as long as the interface is up.
Signed-off-by: Luis Carlos Cobo <luisca@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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: Michael Buesch <mb@bu3sch.de>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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 silences sparse when run on zd1211rw.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch (based on Ron Rindjunsky's) creates a framework for
a unified way to pass BSS configuration to drivers that require
the information, e.g. for implementing power save mode.
This patch introduces new ieee80211_bss_conf structure that is
passed to the driver via the new bss_info_changed() callback
when the BSS configuration changes.
This new BSS configuration infrastructure adds the following
new features:
* drivers are notified of their association AID
* drivers are notified of association status
and replaces the erp_ie_changed() callback. The patch also does
the relevant driver updates for the latter change.
Signed-off-by: Ron Rindjunsky <ron.rindjunsky@intel.com>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch gets rid of the if_id stuff where possible in favour of
a new per-virtual-interface structure "struct ieee80211_vif". This
structure is located at the end of the per-interface structure and
contains a variable length driver-use data area.
This has two advantages:
* removes the need to look up interfaces by if_id, this is better
for working with network namespaces and performance
* allows drivers to store and retrieve per-interface data without
having to allocate own lists/hash tables
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch fixes RX packet alignment issues in the zd1211rw driver.
This is based on a patch by Johannes Berg.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Tested by chloubs on IRC
zd1211 chip 157e:300a 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>
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>
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: Ulrich Kunitz <kune@deine-taler.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The disconnect function can dereference the net_device structure when it
is never allocated. This is the case when ejecting the device installer.
Signed-off-by: Marc Pignat <marc.pignat@hevs.ch>
Acked-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Tested by Su-Jong You
zd1211b chip 0471:1237 v4810 high 00-12-bf AL2230_RF pa0 g--N
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>
Reinhard Speyerer reported at 2007-08-10 a new device.
Here are the information strings.
Product: Telegent TG54USB WLAN Adapter
USB ID: 129b:1666
Chip ID: zd1211 chip 129b:1666 v4330 high 00-01-36 RF2959_RF pa0 -----
FCC ID: N89-UW620Z
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>
It's been a useless no-op for long enough in 2.6 so I figured it's time to
remove it. The number of people that could object because they're
maintaining unified 2.4 and 2.6 drivers is probably rather small.
[ Handled drivers added by netdev tree and some missed IRDA cases... -DaveM ]
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Tested by Nathen Meyers
FCC ID: SI5WUB221Z
zd1211b chip 0586:340a v4810 high 00-13-49 AL2230_RF pa0 ----S
Despite the product name, I'm pretty sure this isn't a MIMO device. It
appears just to be a normal ZD1211B and we have never heard of these
devices having more than 1 RF. I guess they named this product this way
to make it appear that it fits in with the rest of their XtremeMIMO
product range.
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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>
Tested by Giuseppe Lippolis
zd1211b chip 0cde:001a v4810 high 00-60-b3 AL2230_RF pa0 g--NS
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>
This patch cleans up duplicate includes in
drivers/net/
Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
Acked-by: "John W. Linville" <linville@tuxdriver.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
While in monitor mode the zd1211rw received only a limited
set of packets. This patch forwards now all packets the device
receives. Notify that while monitoring no FCS checks are done; so
strange packets might appear in the network sniffer of your
choice.
ATTENTION: Support for multiple interfaces on a single ZD1211
device is currently broken. So this code works only on the first
interface.
Here is an example to put the device in monitor mode.
iwconfig wlan0 mode monitor
ifconfig wlan0 up
iwconfig wlan0 channel 10
[dsd@gentoo.org: backport to mainline]
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 filling the control set the driver tests for a PSPOLL frame.
But it tested only the subtype of the packet. The full type needs
to be tested to identify those packets reliably.
[dsd@gentoo.org: backport to mainline]
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 David Santinoli
zd1211b chip 129b:1667 v4810 high 00-01-e3 AL2230S_RF pa0 ---N-
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch adds the ID for Planex GW-US54GXS USB wireless adapter sold in
Japan.
Since this device returns the regulatory region as 0x49,
the patch 'Allow channels 1-11 for unrecognised regulatory domains' is
required.
Tested by Masakazu Mokuno
zd1211b chip 2019:5303 v4810 high 00-90-cc AL2230_RF pa0 ---N-
Signed-off-by: Masakazu Mokuno <mokuno@sm.sony.co.jp>
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>
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>
Zen Kato has a device which reports the 0xa RF type. The vendor driver
treats this as AL2230S, the same as devices with the AL2230S bit in the POD.
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
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: 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>
This patch adds support for another radio appearing in new devices: the
Ubec UW2453. It's more complicated than the other RF's we support, but
Ubec publish full tech specs so we're able to understand the vendor code
relatively well.
Now that we support UW2453, we also support Atheros' new USB chip: the
AR5007UG. From the little info we have, this appears to be just a
rebranded ZD1211B.
This RF code doesn't work very well -- lots more TX/RX errors than the
other RFs. However, the vendor driver doesn't do any better, so this is
all we can do for now.
[kune@deine-taler.de: bug fixes]
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>
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>
This patch adds support for some new ZD1211B devices which ship with
the AL7230B RF.
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>
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>
Using monitor mode, Johannes Berg observed out that lots of corrupted
and otherwise invalid frames were being passed to the host.
When in monitor mode we were disabling the hardware filtering here, but
this is not how monitor mode should work.
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is a backport of Helge Deller's recent patch for wireless-dev.git
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>
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>
Luis Carlos Cobo