Genar Codina Reverter | 5 Aug 2009 19:59
Picon
Favicon

Latest version of zd1211b and its latest firmware (2009-06-24 01:08)

I would like to add the following information so that the zd1211b.ko module can work with a "LinkSys Model WUSBF5G4 V1.1":

It is necessary to add the following "VendorId and ProductId" (0x13B1, 0x0024) of the "LinkSys Model WUSBF5G4 V1.1" in the "zdusb.c" file:

#ifdef ZD1211B
        { USB_DEVICE(VENDOR_ZYDAS, 0x1215) },
    { USB_DEVICE(VENDOR_ZYDAS, 0xA215) },
#if ZDCONF_FULL_IDS == 1
    { USB_DEVICE(0x0053, 0x5301) },
    { USB_DEVICE(0x0053, 0x5302) },
    { USB_DEVICE(0x13B1, 0x0024) }, //New entry: VendorId, ProductId for "LinkSys Model WUSBF5G4 V1.1"
    { USB_DEVICE(0x2019, 0x5303) }, //Add, 2006.04.17
    { USB_DEVICE(0x050D, 0x4050) },
    { USB_DEVICE(0x050D, 0x705C) },
    { USB_DEVICE(0x0586, 0x340F) },
    { USB_DEVICE(0x079B, 0x0062) },
    { USB_DEVICE(0x083A, 0x4505) },
    { USB_DEVICE(0x083A, 0xE501) },
    { USB_DEVICE(0x0BAF, 0x0121) },
    { USB_DEVICE(0x0CDE, 0x001A) },
    { USB_DEVICE(0x0DF6, 0x9075) },
    { USB_DEVICE(0x0F88, 0x3014) },
    { USB_DEVICE(0x1233, 0x0471) },
    { USB_DEVICE(0x1582, 0x6003) },
    { USB_DEVICE(0x04bb, 0x0938) },
#endif

Without this modification, after being loaded the "zd1211b.ko" module happens that the command "ifconfig -a" cannot detect the device (no information about any ath0 or wlan0, the MAC address of the device, etc).


What can you do with the new Windows Live? Find out
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Gábor Stefanik | 5 Aug 2009 22:31
Picon

Re: Latest version of zd1211b and its latest firmware (2009-06-24 01:08)

On Wed, Aug 5, 2009 at 7:59 PM, Genar Codina
Reverter<genarcodina <at> hotmail.com> wrote:
> I would like to add the following information so that the zd1211b.ko module
> can work with a "LinkSys Model WUSBF5G4 V1.1":
>
> It is necessary to add the following "VendorId and ProductId" (0x13B1,
> 0x0024) of the "LinkSys Model WUSBF5G4 V1.1" in the "zdusb.c" file:
>
> #ifdef ZD1211B
>         { USB_DEVICE(VENDOR_ZYDAS, 0x1215) },
>     { USB_DEVICE(VENDOR_ZYDAS, 0xA215) },
> #if ZDCONF_FULL_IDS == 1
>     { USB_DEVICE(0x0053, 0x5301) },
>     { USB_DEVICE(0x0053, 0x5302) },
>     { USB_DEVICE(0x13B1, 0x0024) }, //New entry: VendorId, ProductId for
> "LinkSys Model WUSBF5G4 V1.1"
>     { USB_DEVICE(0x2019, 0x5303) }, //Add, 2006.04.17
>     { USB_DEVICE(0x050D, 0x4050) },
>     { USB_DEVICE(0x050D, 0x705C) },
>     { USB_DEVICE(0x0586, 0x340F) },
>     { USB_DEVICE(0x079B, 0x0062) },
>     { USB_DEVICE(0x083A, 0x4505) },
>     { USB_DEVICE(0x083A, 0xE501) },
>     { USB_DEVICE(0x0BAF, 0x0121) },
>     { USB_DEVICE(0x0CDE, 0x001A) },
>     { USB_DEVICE(0x0DF6, 0x9075) },
>     { USB_DEVICE(0x0F88, 0x3014) },
>     { USB_DEVICE(0x1233, 0x0471) },
>     { USB_DEVICE(0x1582, 0x6003) },
>     { USB_DEVICE(0x04bb, 0x0938) },
> #endif
>
> Without this modification, after being loaded the "zd1211b.ko" module
> happens that the command "ifconfig -a" cannot detect the device (no
> information about any ath0 or wlan0, the MAC address of the device, etc).

1. The vendor-based driver is no longer developed, the recommended
driver is zd1211rw, which AFAIK already has this ID.
2. I can't find any reference to "WUSBF5G4" anywhere on the web - do
you mean "WUSBF54G"?

--Gábor

--

-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Sören Wellhöfer | 7 Aug 2009 18:47
Picon

[PATCH] UW2453 for TL-WN322G support + 2.6.22.x

While adding support for the TL-WN322G wireless usb adapter on an embedded system I devised a patch to be
applied against the 2.6.22.x kernel to make it work.

It basically integrates support for the uw2453 chip into the zd1211rw driver framework of mentioned
kernel and fixes a few common issues associated with the device. 

Among the problems taken care of are those which are described in this mailing list under the following subjects:
	
	* [zd1211-devs] tp-link WN322G
	* [zd1211-devs] zd1211 on asus A9RP

Cheers,
Sören

Signed-off-by: Sören Wellhöfer <soeren.wellhoefer <at> gmx.net>

---
diff -uprN 2.6.22.6-vanilla/drivers/net/wireless/zd1211rw/Makefile 2.6.22.6/drivers/net/wireless/zd1211rw/Makefile
--- 2.6.22.6-vanilla/drivers/net/wireless/zd1211rw/Makefile	2009-04-23 11:36:28.000000000 +0200
+++ 2.6.22.6/drivers/net/wireless/zd1211rw/Makefile	2009-08-04 08:56:36.000000000 +0200
 <at>  <at>  -2,7 +2,7  <at>  <at>  obj-$(CONFIG_ZD1211RW) += zd1211rw.o

 zd1211rw-objs := zd_chip.o zd_ieee80211.o \
 		zd_mac.o zd_netdev.o \
-		zd_rf_al2230.o zd_rf_rf2959.o \
+		zd_rf_al2230.o zd_rf_rf2959.o zd_rf_uw2453.o\
 		zd_rf_al7230b.o \
 		zd_rf.o zd_usb.o zd_util.o

diff -uprN 2.6.22.6-vanilla/drivers/net/wireless/zd1211rw/zd_chip.h 2.6.22.6/drivers/net/wireless/zd1211rw/zd_chip.h
--- 2.6.22.6-vanilla/drivers/net/wireless/zd1211rw/zd_chip.h	2009-04-23 11:36:28.000000000 +0200
+++ 2.6.22.6/drivers/net/wireless/zd1211rw/zd_chip.h	2009-08-07 16:59:54.000000000 +0200
 <at>  <at>  -720,6 +720,10  <at>  <at>  static inline struct zd_chip *zd_usb_to_
 	return container_of(usb, struct zd_chip, usb);
 }

+static inline int zd_chip_is_zd1211b(struct zd_chip *c) {
+	return c->is_zd1211b;
+}
+
 static inline struct zd_chip *zd_rf_to_chip(struct zd_rf *rf)
 {
 	return container_of(rf, struct zd_chip, rf);
diff -uprN 2.6.22.6-vanilla/drivers/net/wireless/zd1211rw/zd_ieee80211.c 2.6.22.6/drivers/net/wireless/zd1211rw/zd_ieee80211.c
--- 2.6.22.6-vanilla/drivers/net/wireless/zd1211rw/zd_ieee80211.c	2009-04-23
11:36:28.000000000 +0200
+++ 2.6.22.6/drivers/net/wireless/zd1211rw/zd_ieee80211.c	2009-08-07 09:40:07.000000000 +0200
 <at>  <at>  -137,10 +137,14  <at>  <at>  int zd_find_channel(u8 *channel, const s
 {
 	int i, r;
 	u32 mhz;
+	
+	printk(KERN_DEBUG "zd_find_channel(): channel=%d, freq->m=%d\n", *channel, freq->m);

 	if (freq->m < 1000) {
-		if (freq->m  > NUM_CHANNELS || freq->m == 0)
+		if (freq->m  > NUM_CHANNELS || freq->m == 0) {	
+			printk(KERN_DEBUG "zd_find_channel(): failed (1)\n");
 			return -EINVAL;
+		}
 		*channel = freq->m;
 		return 1;
 	}
 <at>  <at>  -156,6 +160,9  <at>  <at>  int zd_find_channel(u8 *channel, const s
 			return 1;
 		}
 	}
+	
+	
+	printk(KERN_DEBUG "zd_find_channel(): failed (2)\n");

 	return -EINVAL;
 }
diff -uprN 2.6.22.6-vanilla/drivers/net/wireless/zd1211rw/zd_mac.c 2.6.22.6/drivers/net/wireless/zd1211rw/zd_mac.c
--- 2.6.22.6-vanilla/drivers/net/wireless/zd1211rw/zd_mac.c	2009-04-23 11:36:28.000000000 +0200
+++ 2.6.22.6/drivers/net/wireless/zd1211rw/zd_mac.c	2009-08-07 09:42:46.000000000 +0200
 <at>  <at>  -536,9 +536,8  <at>  <at>  int zd_mac_request_channel(struct zd_mac
 {
 	unsigned long lock_flags;
 	struct ieee80211_device *ieee = zd_mac_to_ieee80211(mac);
-
-	if (ieee->iw_mode == IW_MODE_INFRA)
-		return -EPERM;
+	
+	printk(KERN_DEBUG "zd_mac_request_channel(): channel=%d\n", channel);

 	spin_lock_irqsave(&mac->lock, lock_flags);
 	if (!zd_regdomain_supports_channel(mac->regdomain, channel)) {
 <at>  <at>  -1195,6 +1194,8  <at>  <at>  static void set_security(struct net_devi
 		}

 	if (sec->flags & SEC_ACTIVE_KEY) {
+		
+		sec->active_key = 1;
 		secinfo->active_key = sec->active_key;
 		dev_dbg_f(zd_mac_dev(zd_netdev_mac(netdev)),
 			"   .active_key = %d\n", sec->active_key);
diff -uprN 2.6.22.6-vanilla/drivers/net/wireless/zd1211rw/zd_rf.c 2.6.22.6/drivers/net/wireless/zd1211rw/zd_rf.c
--- 2.6.22.6-vanilla/drivers/net/wireless/zd1211rw/zd_rf.c	2009-04-23 11:36:28.000000000 +0200
+++ 2.6.22.6/drivers/net/wireless/zd1211rw/zd_rf.c	2009-08-04 15:55:05.000000000 +0200
 <at>  <at>  -25,7 +25,7  <at>  <at> 

 static const char * const rfs[] = {
 	[0]		= "unknown RF0",
-	[1]		= "unknown RF1",
+	[1]		= "unknown RF1", 
 	[UW2451_RF]	= "UW2451_RF",
 	[UCHIP_RF]	= "UCHIP_RF",
 	[AL2230_RF]	= "AL2230_RF",
 <at>  <at>  -52,6 +52,7  <at>  <at>  const char *zd_rf_name(u8 type)
 void zd_rf_init(struct zd_rf *rf)
 {
 	memset(rf, 0, sizeof(*rf));
+	rf->update_channel_int = 1;
 }

 void zd_rf_clear(struct zd_rf *rf)
 <at>  <at>  -81,6 +82,12  <at>  <at>  int zd_rf_init_hw(struct zd_rf *rf, u8 t
 		if (r)
 			return r;
 		break;
+	case MAXIM_NEW_RF:
+	case UW2453_RF:
+		r = zd_rf_init_uw2453(rf);
+		if(r)
+			return r;
+		break;
 	default:
 		dev_err(zd_chip_dev(chip),
 			"RF %s %#x is not supported\n", zd_rf_name(type), type);
diff -uprN 2.6.22.6-vanilla/drivers/net/wireless/zd1211rw/zd_rf.h 2.6.22.6/drivers/net/wireless/zd1211rw/zd_rf.h
--- 2.6.22.6-vanilla/drivers/net/wireless/zd1211rw/zd_rf.h	2009-04-23 11:36:28.000000000 +0200
+++ 2.6.22.6/drivers/net/wireless/zd1211rw/zd_rf.h	2009-08-07 17:00:18.000000000 +0200
 <at>  <at>  -47,6 +47,7  <at>  <at>  struct zd_rf {
 	u8 type;

 	u8 channel;
+	void *priv;

 	/* RF-specific functions */
 	int (*init_hw)(struct zd_rf *rf);
 <at>  <at>  -54,6 +55,9  <at>  <at>  struct zd_rf {
 	int (*switch_radio_on)(struct zd_rf *rf);
 	int (*switch_radio_off)(struct zd_rf *rf);
 	int (*patch_6m_band_edge)(struct zd_rf *rf, u8 channel);
+	void (*clear)(struct zd_rf *rf);
+	
+	u8 update_channel_int:8;
 };

 const char *zd_rf_name(u8 type);
 <at>  <at>  -76,5 +80,6  <at>  <at>  int zd_rf_generic_patch_6m(struct zd_rf 
 int zd_rf_init_rf2959(struct zd_rf *rf);
 int zd_rf_init_al2230(struct zd_rf *rf);
 int zd_rf_init_al7230b(struct zd_rf *rf);
+int zd_rf_init_uw2454(struct zd_rf *rf);

 #endif /* _ZD_RF_H */
diff -uprN 2.6.22.6-vanilla/drivers/net/wireless/zd1211rw/zd_rf_uw2453.c 2.6.22.6/drivers/net/wireless/zd1211rw/zd_rf_uw2453.c
--- 2.6.22.6-vanilla/drivers/net/wireless/zd1211rw/zd_rf_uw2453.c	1970-01-01
01:00:00.000000000 +0100
+++ 2.6.22.6/drivers/net/wireless/zd1211rw/zd_rf_uw2453.c	2009-08-07 17:00:05.000000000 +0200
 <at>  <at>  -0,0 +1,539  <at>  <at> 
+/* ZD1211 USB-WLAN driver for Linux
+ *
+ * Copyright (C) 2005-2007 Ulrich Kunitz <kune <at> deine-taler.de>
+ * Copyright (C) 2006-2007 Daniel Drake <dsd <at> gentoo.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include <linux/kernel.h>
+
+#include "zd_rf.h"
+#include "zd_usb.h"
+#include "zd_chip.h"
+
+#define UW2453_INTR_REG ((zd_addr_t)0x85c1)
+
+/* This RF programming code is based upon the code found in v2.16.0.0 of the
+ * ZyDAS vendor driver. Unlike other RF's, Ubec publish full technical specs
+ * for this RF on their website, so we're able to understand more than
+ * usual as to what is going on. Thumbs up for Ubec for doing that. */
+
+/* The 3-wire serial interface provides access to 8 write-only registers.
+ * The data format is a 4 bit register address followed by a 20 bit value. */
+#define UW2453_REGWRITE(reg, val) ((((reg) & 0xf) << 20) | ((val) & 0xfffff))
+
+/* For channel tuning, we have to configure registers 1 (synthesizer), 2 (synth
+ * fractional divide ratio) and 3 (VCO config).
+ *
+ * We configure the RF to produce an interrupt when the PLL is locked onto
+ * the configured frequency. During initialization, we run through a variety
+ * of different VCO configurations on channel 1 until we detect a PLL lock.
+ * When this happens, we remember which VCO configuration produced the lock
+ * and use it later. Actually, we use the configuration *after* the one that
+ * produced the lock, which seems odd, but it works.
+ *
+ * If we do not see a PLL lock on any standard VCO config, we fall back on an
+ * autocal configuration, which has a fixed (as opposed to per-channel) VCO
+ * config and different synth values from the standard set (divide ratio
+ * is still shared with the standard set). */
+
+/* The per-channel synth values for all standard VCO configurations. These get
+ * written to register 1. */
+static const u8 uw2453_std_synth[] = {
+	RF_CHANNEL( 1) = 0x47,
+	RF_CHANNEL( 2) = 0x47,
+	RF_CHANNEL( 3) = 0x67,
+	RF_CHANNEL( 4) = 0x67,
+	RF_CHANNEL( 5) = 0x67,
+	RF_CHANNEL( 6) = 0x67,
+	RF_CHANNEL( 7) = 0x57,
+	RF_CHANNEL( 8) = 0x57,
+	RF_CHANNEL( 9) = 0x57,
+	RF_CHANNEL(10) = 0x57,
+	RF_CHANNEL(11) = 0x77,
+	RF_CHANNEL(12) = 0x77,
+	RF_CHANNEL(13) = 0x77,
+	RF_CHANNEL(14) = 0x4f,
+};
+
+/* This table stores the synthesizer fractional divide ratio for *all* VCO
+ * configurations (both standard and autocal). These get written to register 2.
+ */
+static const u16 uw2453_synth_divide[] = {
+	RF_CHANNEL( 1) = 0x999,
+	RF_CHANNEL( 2) = 0x99b,
+	RF_CHANNEL( 3) = 0x998,
+	RF_CHANNEL( 4) = 0x99a,
+	RF_CHANNEL( 5) = 0x999,
+	RF_CHANNEL( 6) = 0x99b,
+	RF_CHANNEL( 7) = 0x998,
+	RF_CHANNEL( 8) = 0x99a,
+	RF_CHANNEL( 9) = 0x999,
+	RF_CHANNEL(10) = 0x99b,
+	RF_CHANNEL(11) = 0x998,
+	RF_CHANNEL(12) = 0x99a,
+	RF_CHANNEL(13) = 0x999,
+	RF_CHANNEL(14) = 0xccc,
+};
+
+/* Here is the data for all the standard VCO configurations. We shrink our
+ * table a little by observing that both channels in a consecutive pair share
+ * the same value. We also observe that the high 4 bits ([0:3] in the specs)
+ * are all 'Reserved' and are always set to 0x4 - we chop them off in the data
+ * below. */
+#define CHAN_TO_PAIRIDX(a) ((a - 1) / 2)
+#define RF_CHANPAIR(a,b) [CHAN_TO_PAIRIDX(a)]
+static const u16 uw2453_std_vco_cfg[][7] = {
+	{ /* table 1 */
+		RF_CHANPAIR( 1,  2) = 0x664d,
+		RF_CHANPAIR( 3,  4) = 0x604d,
+		RF_CHANPAIR( 5,  6) = 0x6675,
+		RF_CHANPAIR( 7,  8) = 0x6475,
+		RF_CHANPAIR( 9, 10) = 0x6655,
+		RF_CHANPAIR(11, 12) = 0x6455,
+		RF_CHANPAIR(13, 14) = 0x6665,
+	},
+	{ /* table 2 */
+		RF_CHANPAIR( 1,  2) = 0x666d,
+		RF_CHANPAIR( 3,  4) = 0x606d,
+		RF_CHANPAIR( 5,  6) = 0x664d,
+		RF_CHANPAIR( 7,  8) = 0x644d,
+		RF_CHANPAIR( 9, 10) = 0x6675,
+		RF_CHANPAIR(11, 12) = 0x6475,
+		RF_CHANPAIR(13, 14) = 0x6655,
+	},
+	{ /* table 3 */
+		RF_CHANPAIR( 1,  2) = 0x665d,
+		RF_CHANPAIR( 3,  4) = 0x605d,
+		RF_CHANPAIR( 5,  6) = 0x666d,
+		RF_CHANPAIR( 7,  8) = 0x646d,
+		RF_CHANPAIR( 9, 10) = 0x664d,
+		RF_CHANPAIR(11, 12) = 0x644d,
+		RF_CHANPAIR(13, 14) = 0x6675,
+	},
+	{ /* table 4 */
+		RF_CHANPAIR( 1,  2) = 0x667d,
+		RF_CHANPAIR( 3,  4) = 0x607d,
+		RF_CHANPAIR( 5,  6) = 0x665d,
+		RF_CHANPAIR( 7,  8) = 0x645d,
+		RF_CHANPAIR( 9, 10) = 0x666d,
+		RF_CHANPAIR(11, 12) = 0x646d,
+		RF_CHANPAIR(13, 14) = 0x664d,
+	},
+	{ /* table 5 */
+		RF_CHANPAIR( 1,  2) = 0x6643,
+		RF_CHANPAIR( 3,  4) = 0x6043,
+		RF_CHANPAIR( 5,  6) = 0x667d,
+		RF_CHANPAIR( 7,  8) = 0x647d,
+		RF_CHANPAIR( 9, 10) = 0x665d,
+		RF_CHANPAIR(11, 12) = 0x645d,
+		RF_CHANPAIR(13, 14) = 0x666d,
+	},
+	{ /* table 6 */
+		RF_CHANPAIR( 1,  2) = 0x6663,
+		RF_CHANPAIR( 3,  4) = 0x6063,
+		RF_CHANPAIR( 5,  6) = 0x6643,
+		RF_CHANPAIR( 7,  8) = 0x6443,
+		RF_CHANPAIR( 9, 10) = 0x667d,
+		RF_CHANPAIR(11, 12) = 0x647d,
+		RF_CHANPAIR(13, 14) = 0x665d,
+	},
+	{ /* table 7 */
+		RF_CHANPAIR( 1,  2) = 0x6653,
+		RF_CHANPAIR( 3,  4) = 0x6053,
+		RF_CHANPAIR( 5,  6) = 0x6663,
+		RF_CHANPAIR( 7,  8) = 0x6463,
+		RF_CHANPAIR( 9, 10) = 0x6643,
+		RF_CHANPAIR(11, 12) = 0x6443,
+		RF_CHANPAIR(13, 14) = 0x667d,
+	},
+	{ /* table 8 */
+		RF_CHANPAIR( 1,  2) = 0x6673,
+		RF_CHANPAIR( 3,  4) = 0x6073,
+		RF_CHANPAIR( 5,  6) = 0x6653,
+		RF_CHANPAIR( 7,  8) = 0x6453,
+		RF_CHANPAIR( 9, 10) = 0x6663,
+		RF_CHANPAIR(11, 12) = 0x6463,
+		RF_CHANPAIR(13, 14) = 0x6643,
+	},
+	{ /* table 9 */
+		RF_CHANPAIR( 1,  2) = 0x664b,
+		RF_CHANPAIR( 3,  4) = 0x604b,
+		RF_CHANPAIR( 5,  6) = 0x6673,
+		RF_CHANPAIR( 7,  8) = 0x6473,
+		RF_CHANPAIR( 9, 10) = 0x6653,
+		RF_CHANPAIR(11, 12) = 0x6453,
+		RF_CHANPAIR(13, 14) = 0x6663,
+	},
+	{ /* table 10 */
+		RF_CHANPAIR( 1,  2) = 0x666b,
+		RF_CHANPAIR( 3,  4) = 0x606b,
+		RF_CHANPAIR( 5,  6) = 0x664b,
+		RF_CHANPAIR( 7,  8) = 0x644b,
+		RF_CHANPAIR( 9, 10) = 0x6673,
+		RF_CHANPAIR(11, 12) = 0x6473,
+		RF_CHANPAIR(13, 14) = 0x6653,
+	},
+	{ /* table 11 */
+		RF_CHANPAIR( 1,  2) = 0x665b,
+		RF_CHANPAIR( 3,  4) = 0x605b,
+		RF_CHANPAIR( 5,  6) = 0x666b,
+		RF_CHANPAIR( 7,  8) = 0x646b,
+		RF_CHANPAIR( 9, 10) = 0x664b,
+		RF_CHANPAIR(11, 12) = 0x644b,
+		RF_CHANPAIR(13, 14) = 0x6673,
+	},
+
+};
+
+/* The per-channel synth values for autocal. These get written to register 1. */
+static const u16 uw2453_autocal_synth[] = {
+	RF_CHANNEL( 1) = 0x6847,
+	RF_CHANNEL( 2) = 0x6847,
+	RF_CHANNEL( 3) = 0x6867,
+	RF_CHANNEL( 4) = 0x6867,
+	RF_CHANNEL( 5) = 0x6867,
+	RF_CHANNEL( 6) = 0x6867,
+	RF_CHANNEL( 7) = 0x6857,
+	RF_CHANNEL( 8) = 0x6857,
+	RF_CHANNEL( 9) = 0x6857,
+	RF_CHANNEL(10) = 0x6857,
+	RF_CHANNEL(11) = 0x6877,
+	RF_CHANNEL(12) = 0x6877,
+	RF_CHANNEL(13) = 0x6877,
+	RF_CHANNEL(14) = 0x684f,
+};
+
+/* The VCO configuration for autocal (all channels) */
+static const u16 UW2453_AUTOCAL_VCO_CFG = 0x6662;
+
+/* TX gain settings. The array index corresponds to the TX power integration
+ * values found in the EEPROM. The values get written to register 7. */
+static u32 uw2453_txgain[] = {
+	[0x00] = 0x0e313,
+	[0x01] = 0x0fb13,
+	[0x02] = 0x0e093,
+	[0x03] = 0x0f893,
+	[0x04] = 0x0ea93,
+	[0x05] = 0x1f093,
+	[0x06] = 0x1f493,
+	[0x07] = 0x1f693,
+	[0x08] = 0x1f393,
+	[0x09] = 0x1f35b,
+	[0x0a] = 0x1e6db,
+	[0x0b] = 0x1ff3f,
+	[0x0c] = 0x1ffff,
+	[0x0d] = 0x361d7,
+	[0x0e] = 0x37fbf,
+	[0x0f] = 0x3ff8b,
+	[0x10] = 0x3ff33,
+	[0x11] = 0x3fb3f,
+	[0x12] = 0x3ffff,
+};
+
+/* RF-specific structure */
+struct uw2453_priv {
+	/* index into synth/VCO config tables where PLL lock was found
+	 * -1 means autocal */
+	int config;
+};
+
+#define UW2453_PRIV(rf) ((struct uw2453_priv *) (rf)->priv)
+
+static int uw2453_synth_set_channel(struct zd_chip *chip, int channel,
+	bool autocal)
+{
+	int r;
+	int idx = channel - 1;
+	u32 val;
+
+	if (autocal)
+		val = UW2453_REGWRITE(1, uw2453_autocal_synth[idx]);
+	else
+		val = UW2453_REGWRITE(1, uw2453_std_synth[idx]);
+
+	r = zd_rfwrite_locked(chip, val, RF_RV_BITS);
+	if (r)
+		return r;
+
+	return zd_rfwrite_locked(chip,
+		UW2453_REGWRITE(2, uw2453_synth_divide[idx]), RF_RV_BITS);
+}
+
+static int uw2453_write_vco_cfg(struct zd_chip *chip, u16 value)
+{
+	/* vendor driver always sets these upper bits even though the specs say
+	 * they are reserved */
+	u32 val = 0x40000 | value;
+	return zd_rfwrite_locked(chip, UW2453_REGWRITE(3, val), RF_RV_BITS);
+}
+
+static int uw2453_init_mode(struct zd_chip *chip)
+{
+	static const u32 rv[] = {
+		UW2453_REGWRITE(0, 0x25f98), /* enter IDLE mode */
+		UW2453_REGWRITE(0, 0x25f9a), /* enter CAL_VCO mode */
+		UW2453_REGWRITE(0, 0x25f94), /* enter RX/TX mode */
+		UW2453_REGWRITE(0, 0x27fd4), /* power down RSSI circuit */
+	};
+
+	return zd_rfwritev_locked(chip, rv, ARRAY_SIZE(rv), RF_RV_BITS);
+}
+
+static int uw2453_set_tx_gain_level(struct zd_chip *chip, int channel)
+{
+	u8 int_value = chip->pwr_int_values[channel - 1];
+
+	if (int_value >= ARRAY_SIZE(uw2453_txgain)) {
+		dev_dbg_f(zd_chip_dev(chip), "can't configure TX gain for "
+			  "int value %x on channel %d\n", int_value, channel);
+		return 0;
+	}
+
+	return zd_rfwrite_locked(chip,
+		UW2453_REGWRITE(7, uw2453_txgain[int_value]), RF_RV_BITS);
+}
+
+static int uw2453_init_hw(struct zd_rf *rf)
+{
+	int i, r;
+	int found_config = -1;
+	u16 intr_status;
+	struct zd_chip *chip = zd_rf_to_chip(rf);
+
+	static const struct zd_ioreq16 ioreqs[] = {
+		{ CR10,  0x89 }, { CR15,  0x20 },
+		{ CR17,  0x28 }, /* 6112 no change */
+		{ CR23,  0x38 }, { CR24,  0x20 }, { CR26,  0x93 },
+		{ CR27,  0x15 }, { CR28,  0x3e }, { CR29,  0x00 },
+		{ CR33,  0x28 }, { CR34,  0x30 },
+		{ CR35,  0x43 }, /* 6112 3e->43 */
+		{ CR41,  0x24 }, { CR44,  0x32 },
+		{ CR46,  0x92 }, /* 6112 96->92 */
+		{ CR47,  0x1e },
+		{ CR48,  0x04 }, /* 5602 Roger */
+		{ CR49,  0xfa }, { CR79,  0x58 }, { CR80,  0x30 },
+		{ CR81,  0x30 }, { CR87,  0x0a }, { CR89,  0x04 },
+		{ CR91,  0x00 }, { CR92,  0x0a }, { CR98,  0x8d },
+		{ CR99,  0x28 }, { CR100, 0x02 },
+		{ CR101, 0x09 }, /* 6112 13->1f 6220 1f->13 6407 13->9 */
+		{ CR102, 0x27 },
+		{ CR106, 0x1c }, /* 5d07 5112 1f->1c 6220 1c->1f 6221 1f->1c */
+		{ CR107, 0x1c }, /* 6220 1c->1a 5221 1a->1c */
+		{ CR109, 0x13 },
+		{ CR110, 0x1f }, /* 6112 13->1f 6221 1f->13 6407 13->0x09 */
+		{ CR111, 0x13 }, { CR112, 0x1f }, { CR113, 0x27 },
+		{ CR114, 0x23 }, /* 6221 27->23 */
+		{ CR115, 0x24 }, /* 6112 24->1c 6220 1c->24 */
+		{ CR116, 0x24 }, /* 6220 1c->24 */
+		{ CR117, 0xfa }, /* 6112 fa->f8 6220 f8->f4 6220 f4->fa */
+		{ CR118, 0xf0 }, /* 5d07 6112 f0->f2 6220 f2->f0 */
+		{ CR119, 0x1a }, /* 6112 1a->10 6220 10->14 6220 14->1a */
+		{ CR120, 0x4f },
+		{ CR121, 0x1f }, /* 6220 4f->1f */
+		{ CR122, 0xf0 }, { CR123, 0x57 }, { CR125, 0xad },
+		{ CR126, 0x6c }, { CR127, 0x03 },
+		{ CR128, 0x14 }, /* 6302 12->11 */
+		{ CR129, 0x12 }, /* 6301 10->0f */
+		{ CR130, 0x10 }, { CR137, 0x50 }, { CR138, 0xa8 },
+		{ CR144, 0xac }, { CR146, 0x20 }, { CR252, 0xff },
+		{ CR253, 0xff },
+	};
+
+	static const u32 rv[] = {
+		UW2453_REGWRITE(4, 0x2b),    /* configure reciever gain */
+		UW2453_REGWRITE(5, 0x19e4f), /* configure transmitter gain */
+		UW2453_REGWRITE(6, 0xf81ad), /* enable RX/TX filter tuning */
+		UW2453_REGWRITE(7, 0x3fffe), /* disable TX gain in test mode */
+
+		/* enter CAL_FIL mode, TX gain set by registers, RX gain set by pins,
+		 * RSSI circuit powered down, reduced RSSI range */
+		UW2453_REGWRITE(0, 0x25f9c), /* 5d01 cal_fil */
+
+		/* synthesizer configuration for channel 1 */
+		UW2453_REGWRITE(1, 0x47),
+		UW2453_REGWRITE(2, 0x999),
+
+		/* disable manual VCO band selection */
+		UW2453_REGWRITE(3, 0x7602),
+
+		/* enable manual VCO band selection, configure current level */
+		UW2453_REGWRITE(3, 0x46063),
+	};
+
+	r = zd_iowrite16a_locked(chip, ioreqs, ARRAY_SIZE(ioreqs));
+	if (r)
+		return r;
+
+	r = zd_rfwritev_locked(chip, rv, ARRAY_SIZE(rv), RF_RV_BITS);
+	if (r)
+		return r;
+
+	r = uw2453_init_mode(chip);
+	if (r)
+		return r;
+
+	/* Try all standard VCO configuration settings on channel 1 */
+	for (i = 0; i < ARRAY_SIZE(uw2453_std_vco_cfg) - 1; i++) {
+		/* Configure synthesizer for channel 1 */
+		r = uw2453_synth_set_channel(chip, 1, false);
+		if (r)
+			return r;
+
+		/* Write VCO config */
+		r = uw2453_write_vco_cfg(chip, uw2453_std_vco_cfg[i][0]);
+		if (r)
+			return r;
+
+		/* ack interrupt event */
+		r = zd_iowrite16_locked(chip, 0x0f, UW2453_INTR_REG);
+		if (r)
+			return r;
+
+		/* check interrupt status */
+		r = zd_ioread16_locked(chip, &intr_status, UW2453_INTR_REG);
+		if (r)
+			return r;
+
+		if (!(intr_status & 0xf)) {
+			dev_dbg_f(zd_chip_dev(chip),
+				"PLL locked on configuration %d\n", i);
+			found_config = i;
+			break;
+		}
+	}
+
+	if (found_config == -1) {
+		/* autocal */
+		dev_dbg_f(zd_chip_dev(chip),
+			"PLL did not lock, using autocal\n");
+
+		r = uw2453_synth_set_channel(chip, 1, true);
+		if (r)
+			return r;
+
+		r = uw2453_write_vco_cfg(chip, UW2453_AUTOCAL_VCO_CFG);
+		if (r)
+			return r;
+	}
+
+	/* To match the vendor driver behaviour, we use the configuration after
+	 * the one that produced a lock. */
+	UW2453_PRIV(rf)->config = found_config + 1;
+
+	return zd_iowrite16_locked(chip, 0x06, CR203);
+}
+
+static int uw2453_set_channel(struct zd_rf *rf, u8 channel)
+{
+	int r;
+	u16 vco_cfg;
+	int config = UW2453_PRIV(rf)->config;
+	bool autocal = (config == -1);
+	struct zd_chip *chip = zd_rf_to_chip(rf);
+
+	static const struct zd_ioreq16 ioreqs[] = {
+		{ CR80,  0x30 }, { CR81,  0x30 }, { CR79,  0x58 },
+		{ CR12,  0xf0 }, { CR77,  0x1b }, { CR78,  0x58 },
+	};
+
+	r = uw2453_synth_set_channel(chip, channel, autocal);
+	if (r)
+		return r;
+
+	if (autocal)
+		vco_cfg = UW2453_AUTOCAL_VCO_CFG;
+	else
+		vco_cfg = uw2453_std_vco_cfg[config][CHAN_TO_PAIRIDX(channel)];
+
+	r = uw2453_write_vco_cfg(chip, vco_cfg);
+	if (r)
+		return r;
+
+	r = uw2453_init_mode(chip);
+	if (r)
+		return r;
+
+	r = zd_iowrite16a_locked(chip, ioreqs, ARRAY_SIZE(ioreqs));
+	if (r)
+		return r;
+
+	r = uw2453_set_tx_gain_level(chip, channel);
+	if (r)
+		return r;
+
+	return zd_iowrite16_locked(chip, 0x06, CR203);
+}
+
+static int uw2453_switch_radio_on(struct zd_rf *rf)
+{
+	int r;
+	struct zd_chip *chip = zd_rf_to_chip(rf);
+	struct zd_ioreq16 ioreqs[] = {
+		{ CR11,  0x00 }, { CR251, 0x3f },
+	};
+
+	/* enter RXTX mode */
+	r = zd_rfwrite_locked(chip, UW2453_REGWRITE(0, 0x25f94), RF_RV_BITS);
+	if (r)
+		return r;
+
+	if (zd_chip_is_zd1211b(chip))
+		ioreqs[1].value = 0x7f;
+
+	return zd_iowrite16a_locked(chip, ioreqs, ARRAY_SIZE(ioreqs));
+}
+
+static int uw2453_switch_radio_off(struct zd_rf *rf)
+{
+	int r;
+	struct zd_chip *chip = zd_rf_to_chip(rf);
+	static const struct zd_ioreq16 ioreqs[] = {
+		{ CR11,  0x04 }, { CR251, 0x2f },
+	};
+
+	/* enter IDLE mode */
+	/* FIXME: shouldn't we go to SLEEP? sent email to zydas */
+	r = zd_rfwrite_locked(chip, UW2453_REGWRITE(0, 0x25f90), RF_RV_BITS);
+	if (r)
+		return r;
+
+	return zd_iowrite16a_locked(chip, ioreqs, ARRAY_SIZE(ioreqs));
+}
+
+static void uw2453_clear(struct zd_rf *rf)
+{
+	kfree(rf->priv);
+}
+
+int zd_rf_init_uw2453(struct zd_rf *rf)
+{
+	rf->init_hw = uw2453_init_hw;
+	rf->set_channel = uw2453_set_channel;
+	rf->switch_radio_on = uw2453_switch_radio_on;
+	rf->switch_radio_off = uw2453_switch_radio_off;
+	rf->patch_6m_band_edge = zd_rf_generic_patch_6m;
+	rf->clear = uw2453_clear;
+	/* we have our own TX integration code */
+	rf->update_channel_int = 0;
+
+	rf->priv = kmalloc(sizeof(struct uw2453_priv), GFP_KERNEL);
+	if (rf->priv == NULL)
+		return -ENOMEM;
+
+	return 0;
+}
---

--

-- 
Sören Wellhöfer
Carl-Zeiss-Gymnasium Jena / Specialised school for Math, Science, and Technology

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Hin-Tak Leung | 8 Aug 2009 16:25
Picon
Favicon

Re: [PATCH] UW2453 for TL-WN322G support + 2.6.22.x

--- On Fri, 7/8/09, "Sören Wellhöfer" <Soeren.Wellhoefer <at> gmx.net> wrote:

> While adding support for the
> TL-WN322G wireless usb adapter on an embedded system I
> devised a patch to be applied against the 2.6.22.x kernel to
> make it work.
> 
> It basically integrates support for the uw2453 chip into
> the zd1211rw driver framework of mentioned kernel and fixes
> a few common issues associated with the device. 
> 
> Among the problems taken care of are those which are
> described in this mailing list under the following
> subjects:
>     
>     * [zd1211-devs] tp-link WN322G
>     * [zd1211-devs] zd1211 on asus A9RP
> 
> Cheers,
> Sören
> 
> Signed-off-by: Sören Wellhöfer <soeren.wellhoefer <at> gmx.net>

I appreciate the effort of sharing such changes, personally - don't know if Linus is taking patches for such
old kernels, probably not, so the the signed-off is probably unnecessary :-). I have one comment though -
the patch is neither minimal (you added a couple of strictly-speakingnot-necessary debug print
statements, and there is a whitespace change noted below), nor maximal - maximal would be back-porting
the current code, i.e. a subset of the compat-wireless objective. Have you looked at compat-wireless? I
don't know if it runs as earlier as 2.6.22, but I think it does.

> diff -uprN
> 2.6.22.6-vanilla/drivers/net/wireless/zd1211rw/zd_rf.c
> 2.6.22.6/drivers/net/wireless/zd1211rw/zd_rf.c
> ---
> 2.6.22.6-vanilla/drivers/net/wireless/zd1211rw/zd_rf.c   
> 2009-04-23 11:36:28.000000000 +0200
> +++
> 2.6.22.6/drivers/net/wireless/zd1211rw/zd_rf.c   
> 2009-08-04 15:55:05.000000000 +0200
>  <at>  <at>  -25,7 +25,7  <at>  <at> 
>  
>  static const char * const rfs[] = {
>      [0]   
>     = "unknown RF0",
> -    [1]   
>     = "unknown RF1",
> +    [1]   
>     = "unknown RF1", 
>      [UW2451_RF]    =
> "UW2451_RF",
>      [UCHIP_RF]    =
> "UCHIP_RF",
>      [AL2230_RF]    =
> "AL2230_RF",

White space change, probably unintentional or indicative of a bug?

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Sören Wellhöfer | 8 Aug 2009 18:33
Picon

Re: [PATCH] UW2453 for TL-WN322G support + 2.6.22.x

Hi Hin-Tak,

one of my chief problems was that I was not at all able to get compat-wireless to work with this rather ancient
kernel version. The driver file zd_rf_uw2453.c added in the patch is indeed taken from a recent version of
compat-wireless itself.

Also, I can't really see that the issues I've mentioned got fixed in compat-wireless either. I've seen many
people still reporting problems with this now and then.

My main motivation for the changes were to build the zd1211rw.ko module which I can now load into a
proprietarily-modified kernel on an embedded system (I can't simply build a new kernel for the device
since I lack the BSP).

The white space change was unintended; the debug statements are inserted at points were people seem to get
in trouble.

Sören

> --- On Fri, 7/8/09, "Sören Wellhöfer" <Soeren.Wellhoefer <at> gmx.net> wrote:
> 
> > While adding support for the
> > TL-WN322G wireless usb adapter on an embedded system I
> > devised a patch to be applied against the 2.6.22.x kernel to
> > make it work.
> > 
> > It basically integrates support for the uw2453 chip into
> > the zd1211rw driver framework of mentioned kernel and fixes
> > a few common issues associated with the device. 
> > 
> > Among the problems taken care of are those which are
> > described in this mailing list under the following
> > subjects:
> >     
> >     * [zd1211-devs] tp-link WN322G
> >     * [zd1211-devs] zd1211 on asus A9RP
> > 
> > Cheers,
> > Sören
> > 
> > Signed-off-by: Sören Wellhöfer <soeren.wellhoefer <at> gmx.net>
> 
> I appreciate the effort of sharing such changes, personally - don't know
> if Linus is taking patches for such old kernels, probably not, so the the
> signed-off is probably unnecessary :-). I have one comment though - the patch
> is neither minimal (you added a couple of strictly-speakingnot-necessary
> debug print statements, and there is a whitespace change noted below), nor
> maximal - maximal would be back-porting the current code, i.e. a subset of
> the compat-wireless objective. Have you looked at compat-wireless? I don't
> know if it runs as earlier as 2.6.22, but I think it does.
> 
> > diff -uprN
> > 2.6.22.6-vanilla/drivers/net/wireless/zd1211rw/zd_rf.c
> > 2.6.22.6/drivers/net/wireless/zd1211rw/zd_rf.c
> > ---
> > 2.6.22.6-vanilla/drivers/net/wireless/zd1211rw/zd_rf.c   
> > 2009-04-23 11:36:28.000000000 +0200
> > +++
> > 2.6.22.6/drivers/net/wireless/zd1211rw/zd_rf.c   
> > 2009-08-04 15:55:05.000000000 +0200
> >  <at>  <at>  -25,7 +25,7  <at>  <at> 
> >  
> >  static const char * const rfs[] = {
> >      [0]   
> >     = "unknown RF0",
> > -    [1]   
> >     = "unknown RF1",
> > +    [1]   
> >     = "unknown RF1", 
> >      [UW2451_RF]    =
> > "UW2451_RF",
> >      [UCHIP_RF]    =
> > "UCHIP_RF",
> >      [AL2230_RF]    =
> > "AL2230_RF",
> 
> White space change, probably unintentional or indicative of a bug?
> 
> 
> 
>       

--

-- 
Sören Wellhöfer
Carl-Zeiss-Gymnasium Jena / Specialised school for Math, Science, and Technology

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Hin-Tak Leung | 8 Aug 2009 18:56
Picon
Favicon

Re: [PATCH] UW2453 for TL-WN322G support + 2.6.22.x

--- On Sat, 8/8/09, "Sören Wellhöfer" <Soeren.Wellhoefer <at> gmx.net> wrote:

> Hi Hin-Tak,
> 
> one of my chief problems was that I was not at all able to
> get compat-wireless to work with this rather ancient kernel
> version. The driver file zd_rf_uw2453.c added in the patch
> is indeed taken from a recent version of compat-wireless
> itself.

Here it says there is a version of compat-wireless that went back to 2.6.22, which should be sufficient for
your purpose: 
http://linuxwireless.org/en/users/Download#Compat-wireless_release_types

I think the compat-wireless-old package is slightly older than compat-wireless (which is bleed-edge,
2.6.31/32+), but should take you up to at least about 2.6.28/2.6.29 equivalent, wireless-wise.

> Also, I can't really see that the issues I've mentioned got
> fixed in compat-wireless either. I've seen many people still
> reporting problems with this now and then.

I think you could separate the two types of changes, support of newer UW2453 radio hardware, and fixes to
problems, and send the latter, if they are not in compat-wireless yet, to the linuxwireless mailing list.
I can't quite see at a first glance what problem the non-UW2453-related changes addresses. (and there
hasn't been much traffic on zd1211-devel for months, so remind me...)

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Sören Wellhöfer | 8 Aug 2009 19:46
Picon

Re: [PATCH] UW2453 for TL-WN322G support + 2.6.22.x

Thank you for the link. But as I said, I had problems even with the compat-old version so that patching the old
original kernel to support uw2453 seemed less of a hassle (in terms of getting it to work).

Also, it looks like that for the problems I mentioned there are already a number of smaller patches
addressing it on the linux-wireless mailing list. I haven't taken a closer look but it might be that those
patches have been applied to compat-wireless already and simply aren't included in the compat-old package.

Sören

> --- On Sat, 8/8/09, "Sören Wellhöfer" <Soeren.Wellhoefer <at> gmx.net> wrote:
> 
> > Hi Hin-Tak,
> > 
> > one of my chief problems was that I was not at all able to
> > get compat-wireless to work with this rather ancient kernel
> > version. The driver file zd_rf_uw2453.c added in the patch
> > is indeed taken from a recent version of compat-wireless
> > itself.
> 
> Here it says there is a version of compat-wireless that went back to
> 2.6.22, which should be sufficient for your purpose: 
> http://linuxwireless.org/en/users/Download#Compat-wireless_release_types
> 
> I think the compat-wireless-old package is slightly older than
> compat-wireless (which is bleed-edge, 2.6.31/32+), but should take you up to at least
> about 2.6.28/2.6.29 equivalent, wireless-wise.
> 
> > Also, I can't really see that the issues I've mentioned got
> > fixed in compat-wireless either. I've seen many people still
> > reporting problems with this now and then.
> 
> I think you could separate the two types of changes, support of newer
> UW2453 radio hardware, and fixes to problems, and send the latter, if they are
> not in compat-wireless yet, to the linuxwireless mailing list. I can't
> quite see at a first glance what problem the non-UW2453-related changes
> addresses. (and there hasn't been much traffic on zd1211-devel for months, so
> remind me...)
> 
> 
>       

--

-- 
Sören Wellhöfer
Carl-Zeiss-Gymnasium Jena / Specialised school for Math, Science, and Technology

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Hin-Tak Leung | 18 Aug 2009 03:44
Picon
Favicon

Re: zd1211rw couldn't load firmware. Error number -145 with Kernel 2.6.30

--- On Thu, 30/7/09, Hin-Tak Leung <hintak_leung <at> yahoo.co.uk> wrote:

> --- On Thu, 30/7/09, Mladen Horvat
> <acid-burn <at> opendreambox.org>
> wrote:
> 
> > Ok, finally managed with the help of a friend to
> compile
> > the vender driver
> > 3.0.0.56 with the mips 2.6.30 kernel i use here.
> > Here is a patch that was needed to get it finally
> compiled
> > under 2.6.30.
> > http://pastebin.com/m17687d4e
> 
> Hmm, the net_ops is new and should only generates a warning
> with vanilla 2.6.30 . Your kernel source tree is not vanilla
> 2.6.30, is it? If you need the net_ops change, your tree is
> probably closer to 2.6.31 rcX . (since it generates a
> warning on ifconfig up, I know about it and it is just not
> urgent/immediate yet in 2.6.30)

I went and looked at the git log detail of the net_device_ops change (
commit d314774cf2cd5dfeb39a00d37deee65d4c627927
Author: Stephen Hemminger <shemminger <at> vyatta.com>
Date:   Wed Nov 19 21:32:24 2008 -0800) and it was introduced in 2.6.28, actually.  But we are both right! The
change allows for optional backward compatibility, while emitting a warning. The default is yes:
CONFIG_COMPAT_NET_DEV_OPS/COMPAT_NET_DEV_OPS=y .   
So I left it at 'yes' (fedora 11 vendor kernel in one of my boxes, custom kernel on the other box, but I normally
just do 'make oldconfig', so I inherited the default) in both of my boxes. 

It seems that you have opted for 'no' manually, so you needed to migrate to the net_device_ops api structure
right away. Interesting differences - same source tree, just different kernel build options. Mystery
solved. :-)

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

Gmane