[PATCH] zd1211rw: six urgent upstream fixes

[PATCH] zd1211rw: six urgent upstream fixes

[Ulrich Kunitz]

Here are six fixes for the zd1211rw driver.

They fix
 - radiotap issues for the monitor mode
 - WEP encryption
 - an endianess problem in the rx path
 - reassociation after disassociation be the AP

If possible these patches should be included in 2.6.18

-- Uli

[PATCH 1/6] zd1211rw: Fixes radiotap header

[Ulrich Kunitz]

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: Ulrich Kunitz <kune@deine-taler.de>
---
 drivers/net/wireless/zd1211rw/zd_mac.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/zd1211rw/zd_mac.c b/drivers/net/wireless/zd1211rw/zd_mac.c
index 3bdc54d..b394303 100644
--- a/drivers/net/wireless/zd1211rw/zd_mac.c
+++ b/drivers/net/wireless/zd1211rw/zd_mac.c
@@ -713,10 +713,10 @@ static int zd_mac_tx(struct zd_mac *mac,
 struct zd_rt_hdr {
 	struct ieee80211_radiotap_header rt_hdr;
 	u8  rt_flags;
+	u8  rt_rate;
 	u16 rt_channel;
 	u16 rt_chbitmask;
-	u16 rt_rate;
-};
+} __attribute__((packed));
 
 static void fill_rt_header(void *buffer, struct zd_mac *mac,
 	                   const struct ieee80211_rx_stats *stats,
@@ -735,14 +735,14 @@ static void fill_rt_header(void *buffer,
 	if (status->decryption_type & (ZD_RX_WEP64|ZD_RX_WEP128|ZD_RX_WEP256))
 		hdr->rt_flags |= IEEE80211_RADIOTAP_F_WEP;
 
+	hdr->rt_rate = stats->rate / 5;
+
 	/* FIXME: 802.11a */
 	hdr->rt_channel = cpu_to_le16(ieee80211chan2mhz(
 		                             _zd_chip_get_channel(&mac->chip)));
 	hdr->rt_chbitmask = cpu_to_le16(IEEE80211_CHAN_2GHZ |
 		((status->frame_status & ZD_RX_FRAME_MODULATION_MASK) ==
 		ZD_RX_OFDM ? IEEE80211_CHAN_OFDM : IEEE80211_CHAN_CCK));
-
-	hdr->rt_rate = stats->rate / 5;
 }
 
 /* Returns 1 if the data packet is for us and 0 otherwise. */
-- 
1.4.1

[PATCH 2/6] zd1211rw: Pass more management frame types up to host

[Ulrich Kunitz]

From: Daniel Drake <dsd@gentoo.org>

We'll be needing these at some point...

Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: Ulrich Kunitz <kune@deine-taler.de>
---
 drivers/net/wireless/zd1211rw/zd_chip.h |    4 +++-
 drivers/net/wireless/zd1211rw/zd_mac.c  |    6 ++++--
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/zd1211rw/zd_chip.h b/drivers/net/wireless/zd1211rw/zd_chip.h
index 8051210..0eb9c8f 100644
--- a/drivers/net/wireless/zd1211rw/zd_chip.h
+++ b/drivers/net/wireless/zd1211rw/zd_chip.h
@@ -461,10 +461,12 @@ #define CR_UNDERRUN_CNT			CTL_REG(0x0688
 
 #define CR_RX_FILTER			CTL_REG(0x068c)
 #define RX_FILTER_ASSOC_RESPONSE	0x0002
+#define RX_FILTER_REASSOC_RESPONSE	0x0008
 #define RX_FILTER_PROBE_RESPONSE	0x0020
 #define RX_FILTER_BEACON		0x0100
+#define RX_FILTER_DISASSOC		0x0400
 #define RX_FILTER_AUTH			0x0800
-/* Sniff modus sets filter to 0xfffff */
+/* Monitor mode sets filter to 0xfffff */
 
 #define CR_ACK_TIMEOUT_EXT		CTL_REG(0x0690)
 #define CR_BCN_FIFO_SEMAPHORE		CTL_REG(0x0694)
diff --git a/drivers/net/wireless/zd1211rw/zd_mac.c b/drivers/net/wireless/zd1211rw/zd_mac.c
index b394303..1cf1fda 100644
--- a/drivers/net/wireless/zd1211rw/zd_mac.c
+++ b/drivers/net/wireless/zd1211rw/zd_mac.c
@@ -136,8 +136,10 @@ static int reset_mode(struct zd_mac *mac
 {
 	struct ieee80211_device *ieee = zd_mac_to_ieee80211(mac);
 	struct zd_ioreq32 ioreqs[3] = {
-		{ CR_RX_FILTER, RX_FILTER_BEACON|RX_FILTER_PROBE_RESPONSE|
-			        RX_FILTER_AUTH|RX_FILTER_ASSOC_RESPONSE },
+		{ CR_RX_FILTER, RX_FILTER_BEACON | RX_FILTER_PROBE_RESPONSE |
+			        RX_FILTER_AUTH | RX_FILTER_ASSOC_RESPONSE |
+				RX_FILTER_REASSOC_RESPONSE |
+				RX_FILTER_DISASSOC },
 		{ CR_SNIFFER_ON, 0U },
 		{ CR_ENCRYPTION_TYPE, NO_WEP },
 	};
-- 
1.4.1

[PATCH 3/6] zd1211rw: Fix software encryption/decryption

[Ulrich Kunitz]

From: Daniel Drake <dsd@gentoo.org>

Apparently the ZD1211 doesn't mind, but the ZD1211B absolutely must be
told that encryption is happening in software.

Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: Ulrich Kunitz <kune@deine-taler.de>
---
 drivers/net/wireless/zd1211rw/zd_mac.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/zd1211rw/zd_mac.c b/drivers/net/wireless/zd1211rw/zd_mac.c
index 1cf1fda..a66625c 100644
--- a/drivers/net/wireless/zd1211rw/zd_mac.c
+++ b/drivers/net/wireless/zd1211rw/zd_mac.c
@@ -108,7 +108,9 @@ int zd_mac_init_hw(struct zd_mac *mac, u
 	if (r)
 		goto disable_int;
 
-	r = zd_set_encryption_type(chip, NO_WEP);
+	/* We must inform the device that we are doing encryption/decryption in
+	 * software at the moment. */
+	r = zd_set_encryption_type(chip, ENC_SNIFFER);
 	if (r)
 		goto disable_int;
 
@@ -141,7 +143,6 @@ static int reset_mode(struct zd_mac *mac
 				RX_FILTER_REASSOC_RESPONSE |
 				RX_FILTER_DISASSOC },
 		{ CR_SNIFFER_ON, 0U },
-		{ CR_ENCRYPTION_TYPE, NO_WEP },
 	};
 
 	if (ieee->iw_mode == IW_MODE_MONITOR) {
-- 
1.4.1

[PATCH 4/6] zd1211rw: Remove bogus assert

[Ulrich Kunitz]

From: Daniel Drake <dsd@gentoo.org>

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>
---
 drivers/net/wireless/zd1211rw/zd_usb.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/net/wireless/zd1211rw/zd_usb.c b/drivers/net/wireless/zd1211rw/zd_usb.c
index c68b9f8..2e3d77e 100644
--- a/drivers/net/wireless/zd1211rw/zd_usb.c
+++ b/drivers/net/wireless/zd1211rw/zd_usb.c
@@ -325,7 +325,6 @@ static void disable_read_regs_int(struct
 {
 	struct zd_usb_interrupt *intr = &usb->intr;
 
-	ZD_ASSERT(in_interrupt());
 	spin_lock(&intr->lock);
 	intr->read_regs_enabled = 0;
 	spin_unlock(&intr->lock);
-- 
1.4.1

[PATCH 5/6] zd1211rw: Fixed endianess issue with length info tag detection

[Ulrich Kunitz]

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>
---
 drivers/net/wireless/zd1211rw/zd_usb.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/zd1211rw/zd_usb.c b/drivers/net/wireless/zd1211rw/zd_usb.c
index 2e3d77e..96551da 100644
--- a/drivers/net/wireless/zd1211rw/zd_usb.c
+++ b/drivers/net/wireless/zd1211rw/zd_usb.c
@@ -546,11 +546,11 @@ static void handle_rx_packet(struct zd_u
 	 * be padded. Unaligned access might also happen if the length_info
 	 * structure is not present.
 	 */
-	if (get_unaligned(&length_info->tag) == RX_LENGTH_INFO_TAG) {
+	if (get_unaligned(&length_info->tag) == cpu_to_le16(RX_LENGTH_INFO_TAG))
+	{
 		unsigned int l, k, n;
 		for (i = 0, l = 0;; i++) {
-			k = le16_to_cpu(get_unaligned(
-				&length_info->length[i]));
+			k = le16_to_cpu(get_unaligned(&length_info->length[i]));
 			n = l+k;
 			if (n > length)
 				return;
-- 
1.4.1

[PATCH 6/6] zd1211rw: Packet filter fix for managed (STA) mode

[Ulrich Kunitz]

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>
---
 drivers/net/wireless/zd1211rw/zd_chip.c |    4 ++--
 drivers/net/wireless/zd1211rw/zd_chip.h |    6 +++---
 drivers/net/wireless/zd1211rw/zd_mac.c  |    5 +----
 3 files changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wireless/zd1211rw/zd_chip.c b/drivers/net/wireless/zd1211rw/zd_chip.c
index efc9c4b..da9d06b 100644
--- a/drivers/net/wireless/zd1211rw/zd_chip.c
+++ b/drivers/net/wireless/zd1211rw/zd_chip.c
@@ -797,7 +797,7 @@ static int zd1211_hw_init_hmac(struct zd
 		{ CR_ADDA_MBIAS_WARMTIME,	0x30000808 },
 		{ CR_ZD1211_RETRY_MAX,		0x2 },
 		{ CR_SNIFFER_ON,		0 },
-		{ CR_RX_FILTER,			AP_RX_FILTER },
+		{ CR_RX_FILTER,			STA_RX_FILTER },
 		{ CR_GROUP_HASH_P1,		0x00 },
 		{ CR_GROUP_HASH_P2,		0x80000000 },
 		{ CR_REG1,			0xa4 },
@@ -844,7 +844,7 @@ static int zd1211b_hw_init_hmac(struct z
 		{ CR_ZD1211B_AIFS_CTL2,		0x008C003C },
 		{ CR_ZD1211B_TXOP,		0x01800824 },
 		{ CR_SNIFFER_ON,		0 },
-		{ CR_RX_FILTER,			AP_RX_FILTER },
+		{ CR_RX_FILTER,			STA_RX_FILTER },
 		{ CR_GROUP_HASH_P1,		0x00 },
 		{ CR_GROUP_HASH_P2,		0x80000000 },
 		{ CR_REG1,			0xa4 },
diff --git a/drivers/net/wireless/zd1211rw/zd_chip.h b/drivers/net/wireless/zd1211rw/zd_chip.h
index 0eb9c8f..069d2b4 100644
--- a/drivers/net/wireless/zd1211rw/zd_chip.h
+++ b/drivers/net/wireless/zd1211rw/zd_chip.h
@@ -466,6 +466,9 @@ #define RX_FILTER_PROBE_RESPONSE	0x0020
 #define RX_FILTER_BEACON		0x0100
 #define RX_FILTER_DISASSOC		0x0400
 #define RX_FILTER_AUTH			0x0800
+#define AP_RX_FILTER			0x0400feff
+#define STA_RX_FILTER			0x0000ffff
+
 /* Monitor mode sets filter to 0xfffff */
 
 #define CR_ACK_TIMEOUT_EXT		CTL_REG(0x0690)
@@ -548,9 +551,6 @@ #define CR_ZD1211B_AIFS_CTL2		CTL_REG(0x
 #define CR_ZD1211B_TXOP			CTL_REG(0x0b20)
 #define CR_ZD1211B_RETRY_MAX		CTL_REG(0x0b28)
 
-#define AP_RX_FILTER			0x0400feff
-#define STA_RX_FILTER			0x0000ffff
-
 #define CWIN_SIZE			0x007f043f
 
 
diff --git a/drivers/net/wireless/zd1211rw/zd_mac.c b/drivers/net/wireless/zd1211rw/zd_mac.c
index a66625c..d6f3e02 100644
--- a/drivers/net/wireless/zd1211rw/zd_mac.c
+++ b/drivers/net/wireless/zd1211rw/zd_mac.c
@@ -138,10 +138,7 @@ static int reset_mode(struct zd_mac *mac
 {
 	struct ieee80211_device *ieee = zd_mac_to_ieee80211(mac);
 	struct zd_ioreq32 ioreqs[3] = {
-		{ CR_RX_FILTER, RX_FILTER_BEACON | RX_FILTER_PROBE_RESPONSE |
-			        RX_FILTER_AUTH | RX_FILTER_ASSOC_RESPONSE |
-				RX_FILTER_REASSOC_RESPONSE |
-				RX_FILTER_DISASSOC },
+		{ CR_RX_FILTER, STA_RX_FILTER },
 		{ CR_SNIFFER_ON, 0U },
 	};
 
-- 
1.4.1

Re: [PATCH 2/6] zd1211rw: Pass more management frame types up to host

[John W. Linville]

On Tue, Aug 01, 2006 at 11:43:31PM +0200, Ulrich Kunitz wrote:
> From: Daniel Drake <dsd@gentoo.org>
> 
> We'll be needing these at some point...

This one doesn't really seem like a fix.  But since the later fixes
seem to depend on it, I guess it makes sense to take it.

I just didn't want you to think I wasn't looking... :-)

John
-- 
John W. Linville
linville@tuxdriver.com

Re: [PATCH 2/6] zd1211rw: Pass more management frame types up to host

[Ulrich Kunitz]

On 06-08-02 17:58 John W. Linville wrote:

> On Tue, Aug 01, 2006 at 11:43:31PM +0200, Ulrich Kunitz wrote:
> > From: Daniel Drake <dsd@gentoo.org>
> > 
> > We'll be needing these at some point...
> 
> This one doesn't really seem like a fix.  But since the later fixes
> seem to depend on it, I guess it makes sense to take it.
> 
> I just didn't want you to think I wasn't looking... :-)

John,

you are absolutely right. The patch is needed, because the patch
sequence would break without it.

Would it be acceptable if I hint on such "bridge" patches in the
futture or should we create a clean patch sequence? The latter would
require us to rewrite patches manually.

BTW we will have a greater number of patches for 2.6.19 (around 30),
which supports more devices and also cleans stuff. Some work is
however still required.

Regards,

Uli

-- 
Uli Kunitz

Re: [PATCH 2/6] zd1211rw: Pass more management frame types up to host

[John W. Linville]

On Thu, Aug 03, 2006 at 08:09:06AM +0200, Ulrich Kunitz wrote:

> Would it be acceptable if I hint on such "bridge" patches in the
> futture or should we create a clean patch sequence? The latter would
> require us to rewrite patches manually.

I was mostly just poking fun at you. :-)  Still, I suppose it wouldn't
hurt to acknowledge when a "not really a fix" patch is being included.

When the trivial "not really a fix" patch becomes a non-trivial "really
a new feature" patch, then we create a situation that may force the
feature patch and all it's dependant patches to be pushed to the next
merge window.  In that case, if the later fixes are important than
the patch sequence may need to be rewritten.

> BTW we will have a greater number of patches for 2.6.19 (around 30),
> which supports more devices and also cleans stuff. Some work is
> however still required.

That sounds great.  Please do get them in ASAP (after reasonable
testing, of course).  There was some talk at the kernel summit of
requiring all feature patches to be in the sub-maintainer trees BEFORE
Linus opens the merge window.  I'm not sure that was fully agreed upon,
but still earlier is better.

John
-- 
John W. Linville
linville@tuxdriver.com