Nabble - zd1211-devs

Where I can find the zd1211 datasheet?

2009-11-01T18:47:50Z

Hi experts,

I am looking for the zd1211 chipset datasheet/manual, is there anyone
can point out me where I can find it?Or send to me off line?
Very appreciated.

BTW,I check www.zydas.com.tw find nothing.

Thanks very much
Tomas W

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs

Re: LinuxUSB_AR2524-3.0.0.56_2009May_pathset

2009-10-29T00:08:50Z

--- On Thu, 29/10/09, Daniel Schmitt <daniel.schmitt@...> wrote:

> Hello Hin-Tak,
>
> this URL does not work either:
> http://htl10.users.sourceforge.net/LinuxUSB_AR2524-3.0.0.56_2009May_pathset/
>
> Can you please mail me a .tar.bz-archive of the patches you
> did for the
> ZD1211 3.00 Vendor driver?
> I want to get AP mode running and this doesn't work with
> zd1211rw driver.
>
> Thanks,
> Daniel
>
>

Sorry, I moved it slightly:
http://htl10.users.sourceforge.net/patchsets/LinuxUSB_AR2524-3.0.0.56/

and withdrawn patch 04 (which I inherit from somebody), which seems to be not needed and breaks 64-bit platform; there were also two new patches which ports it forward to 2.6.30/2.6.31 since I last wrote.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs

zyxtel G-202 AP mode

2009-10-27T16:32:29Z

Hello,

Trying to get this card to work in AP mode. We have tried the zd1211rw module and the old zd1211b module. The card will start into ap mode with Hostapd, and can see it broadcasting but we are unable to associate to the card, with encryption on or off. Can anyone point me in the right direction to get this working. Working on RedHat 2.6.18-rc6 kernel. I know the kernel is old but that is what has to be used. I am kind of running out of ideas here on getting this working.

[PATCH] zd1211rw: Fix TX status reporting in order to have proper rate control

2009-10-22T03:04:52Z

First, we reduce the number of hardware retries to 0 (ie 2 real retries
for each rate). Next, when we report the retries to mac80211, we always
report a retry count of 1 (it seems to be 2 in fact, but using 2 seems
to lead to wrong performance for some reason). We use a state machine to
determine the real fate of a packet based on the 802.11 ACK and what the
Zydas hardware is saying when a real retry occurs. The real retry rates
are encoded in a static array. It has been tested with both zd1211 and
zd1211b hardware. Of course, since the Zydas hardware is not reporting
retries accurately, we are just doing our best in order to get the best
performance (ie higher throughput).

Signed-off-by: Benoit PAPILLAULT <benoit.papillault@...>
---
drivers/net/wireless/zd1211rw/zd_chip.c | 4 +-
drivers/net/wireless/zd1211rw/zd_chip.h | 18 +++-
drivers/net/wireless/zd1211rw/zd_mac.c | 204 +++++++++++++++++++++++++++---
drivers/net/wireless/zd1211rw/zd_mac.h | 25 ++++-
drivers/net/wireless/zd1211rw/zd_usb.c | 4 +-
5 files changed, 228 insertions(+), 27 deletions(-)

diff --git a/drivers/net/wireless/zd1211rw/zd_chip.c b/drivers/net/wireless/zd1211rw/zd_chip.c
index 5e110a2..43b476d 100644
--- a/drivers/net/wireless/zd1211rw/zd_chip.c
+++ b/drivers/net/wireless/zd1211rw/zd_chip.c
@@ -755,7 +755,7 @@ static int hw_reset_phy(struct zd_chip *chip)
static int zd1211_hw_init_hmac(struct zd_chip *chip)
{
static const struct zd_ioreq32 ioreqs[] = {
- { CR_ZD1211_RETRY_MAX, 0x2 },
+ { CR_ZD1211_RETRY_MAX, ZD1211_RETRY_COUNT },
{ CR_RX_THRESHOLD, 0x000c0640 },
};

@@ -767,7 +767,7 @@ static int zd1211_hw_init_hmac(struct zd_chip *chip)
static int zd1211b_hw_init_hmac(struct zd_chip *chip)
{
static const struct zd_ioreq32 ioreqs[] = {
- { CR_ZD1211B_RETRY_MAX, 0x02020202 },
+ { CR_ZD1211B_RETRY_MAX, ZD1211B_RETRY_COUNT },
{ CR_ZD1211B_CWIN_MAX_MIN_AC0, 0x007f003f },
{ CR_ZD1211B_CWIN_MAX_MIN_AC1, 0x007f003f },
{ CR_ZD1211B_CWIN_MAX_MIN_AC2, 0x003f001f },
diff --git a/drivers/net/wireless/zd1211rw/zd_chip.h b/drivers/net/wireless/zd1211rw/zd_chip.h
index 678c139..9fd8f35 100644
--- a/drivers/net/wireless/zd1211rw/zd_chip.h
+++ b/drivers/net/wireless/zd1211rw/zd_chip.h
@@ -642,13 +642,29 @@ enum {
#define CR_ZD1211B_TXOP CTL_REG(0x0b20)
#define CR_ZD1211B_RETRY_MAX CTL_REG(0x0b28)

+/* Value for CR_ZD1211_RETRY_MAX & CR_ZD1211B_RETRY_MAX. Vendor driver uses 2,
+ * we use 0. The first rate is tried (count+2), then all next rates are tried
+ * twice, until 1 Mbits is tried. */
+#define ZD1211_RETRY_COUNT 0
+#define ZD1211B_RETRY_COUNT \
+ (ZD1211_RETRY_COUNT << 0)| \
+ (ZD1211_RETRY_COUNT << 8)| \
+ (ZD1211_RETRY_COUNT << 16)| \
+ (ZD1211_RETRY_COUNT << 24)
+
/* Used to detect PLL lock */
#define UW2453_INTR_REG ((zd_addr_t)0x85c1)

#define CWIN_SIZE 0x007f043f

-#define HWINT_ENABLED 0x004f0000
+#define HWINT_ENABLED \
+ (INT_TX_COMPLETE_EN| \
+ INT_RX_COMPLETE_EN| \
+ INT_RETRY_FAIL_EN| \
+ INT_WAKEUP_EN| \
+ INT_CFG_NEXT_BCN_EN)
+
#define HWINT_DISABLED 0

#define E2P_PWR_INT_GUARD 8
diff --git a/drivers/net/wireless/zd1211rw/zd_mac.c b/drivers/net/wireless/zd1211rw/zd_mac.c
index 6d66635..8ca85d8 100644
--- a/drivers/net/wireless/zd1211rw/zd_mac.c
+++ b/drivers/net/wireless/zd1211rw/zd_mac.c
@@ -88,6 +88,34 @@ static const struct ieee80211_rate zd_rates[] = {
.flags = 0 },
};

+/*
+ * Zydas retry rates table. Each line is listed in the same order as
+ * in zd_rates[] and contains all the rate used when a packet is sent
+ * starting with a given rates. Let's consider an example :
+ *
+ * "11 Mbits : 4, 3, 2, 1, 0" means :
+ * - packet is sent using 4 different rates
+ * - 1st rate is index 3 (ie 11 Mbits)
+ * - 2nd rate is index 2 (ie 5.5 Mbits)
+ * - 3rd rate is index 1 (ie 2 Mbits)
+ * - 4th rate is index 0 (ie 1 Mbits)
+ */
+
+static const struct tx_retry_rate zd_retry_rates[] = {
+ { /* 1 Mbits */ 1, { 0 }},
+ { /* 2 Mbits */ 2, { 1, 0 }},
+ { /* 5.5 Mbits */ 3, { 2, 1, 0 }},
+ { /* 11 Mbits */ 4, { 3, 2, 1, 0 }},
+ { /* 6 Mbits */ 5, { 4, 3, 2, 1, 0 }},
+ { /* 9 Mbits */ 6, { 5, 4, 3, 2, 1, 0}},
+ { /* 12 Mbits */ 5, { 6, 3, 2, 1, 0 }},
+ { /* 18 Mbits */ 6, { 7, 6, 3, 2, 1, 0 }},
+ { /* 24 Mbits */ 6, { 8, 6, 3, 2, 1, 0 }},
+ { /* 36 Mbits */ 7, { 9, 8, 6, 3, 2, 1, 0 }},
+ { /* 48 Mbits */ 8, {10, 9, 8, 6, 3, 2, 1, 0 }},
+ { /* 54 Mbits */ 9, {11, 10, 9, 8, 6, 3, 2, 1, 0 }}
+};
+
static const struct ieee80211_channel zd_channels[] = {
{ .center_freq = 2412, .hw_value = 1 },
{ .center_freq = 2417, .hw_value = 2 },
@@ -282,7 +310,7 @@ static void zd_op_stop(struct ieee80211_hw *hw)
}

/**
- * tx_status - reports tx status of a packet if required
+ * zd_mac_tx_status - reports tx status of a packet if required
* @hw - a &struct ieee80211_hw pointer
* @skb - a sk-buffer
* @flags: extra flags to set in the TX status info
@@ -295,15 +323,49 @@ static void zd_op_stop(struct ieee80211_hw *hw)
*
* If no status information has been requested, the skb is freed.
*/
-static void tx_status(struct ieee80211_hw *hw, struct sk_buff *skb,
- int ackssi, bool success)
+static void zd_mac_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb,
+ int ackssi, struct tx_status *tx_status)
{
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
-
+ int i;
+ int success = 1, retry = 1;
+ int first_idx;
+ const struct tx_retry_rate *retries;
+
ieee80211_tx_info_clear_status(info);

- if (success)
+ if (tx_status) {
+ success = !tx_status->failure;
+ retry = tx_status->retry + success;
+ }
+
+ if (success) {
+ /* success */
info->flags |= IEEE80211_TX_STAT_ACK;
+ } else {
+ /* failure */
+ info->flags &= ~IEEE80211_TX_STAT_ACK;
+ }
+
+ first_idx = info->status.rates[0].idx;
+ ZD_ASSERT(0<=first_idx && first_idx<ARRAY_SIZE(zd_retry_rates));
+ retries = &zd_retry_rates[first_idx];
+ ZD_ASSERT(0<=retry && retry<=retries->count);
+
+ info->status.rates[0].idx = retries->rate[0];
+ info->status.rates[0].count = 1; // (retry > 1 ? 2 : 1);
+
+ for (i=1; i<IEEE80211_TX_MAX_RATES-1 && i<retry; i++) {
+ info->status.rates[i].idx = retries->rate[i];
+ info->status.rates[i].count = 1; // ((i==retry-1) && success ? 1:2);
+ }
+ for (; i<IEEE80211_TX_MAX_RATES && i<retry; i++) {
+ info->status.rates[i].idx = retries->rate[retry-1];
+ info->status.rates[i].count = 1; // (success ? 1:2);
+ }
+ if (i<IEEE80211_TX_MAX_RATES)
+ info->status.rates[i].idx = -1; /* terminate */
+
info->status.ack_signal = ackssi;
ieee80211_tx_status_irqsafe(hw, skb);
}
@@ -316,16 +378,79 @@ static void tx_status(struct ieee80211_hw *hw, struct sk_buff *skb,
* transferred. The first frame from the tx queue, will be selected and
* reported as error to the upper layers.
*/
-void zd_mac_tx_failed(struct ieee80211_hw *hw)
+void zd_mac_tx_failed(struct urb *urb)
{
- struct sk_buff_head *q = &zd_hw_mac(hw)->ack_wait_queue;
+ struct ieee80211_hw * hw = zd_usb_to_hw(urb->context);
+ struct zd_mac *mac = zd_hw_mac(hw);
+ struct sk_buff_head *q = &mac->ack_wait_queue;
struct sk_buff *skb;
+ struct tx_status *tx_status = (struct tx_status *)urb->transfer_buffer;
+ unsigned long flags;
+ int success = !tx_status->failure;
+ int retry = tx_status->retry + success;
+ int found = 0;
+ int i, position = 0;

- skb = skb_dequeue(q);
- if (skb == NULL)
- return;
+ q = &mac->ack_wait_queue;
+ spin_lock_irqsave(&q->lock, flags);

- tx_status(hw, skb, 0, 0);
+ skb_queue_walk(q, skb) {
+ struct ieee80211_hdr *tx_hdr;
+ struct ieee80211_tx_info *info;
+ int first_idx, final_idx;
+ const struct tx_retry_rate *retries;
+ u8 final_rate;
+
+ position ++;
+
+ /* if the hardware reports a failure and we had a 802.11 ACK
+ * pending, then we skip the first skb when searching for a
+ * matching frame */
+ if (tx_status->failure && mac->ack_pending &&
+ skb_queue_is_first(q, skb)) {
+ continue;
+ }
+
+ tx_hdr = (struct ieee80211_hdr *)skb->data;
+
+ /* we skip all frames not matching the reported destination */
+ if (unlikely(memcmp(tx_hdr->addr1, tx_status->mac, ETH_ALEN))) {
+ continue;
+ }
+
+ /* we skip all frames not matching the reported final rate */
+
+ info = IEEE80211_SKB_CB(skb);
+ first_idx = info->status.rates[0].idx;
+ ZD_ASSERT(0<=first_idx && first_idx<ARRAY_SIZE(zd_retry_rates));
+ retries = &zd_retry_rates[first_idx];
+ if (retry < 0 || retry > retries->count) {
+ continue;
+ }
+
+ ZD_ASSERT(0<=retry && retry<=retries->count);
+ final_idx = retries->rate[retry-1];
+ final_rate = zd_rates[final_idx].hw_value;
+
+ if (final_rate != tx_status->rate) {
+ continue;
+ }
+
+ found = 1;
+ break;
+ }
+
+ if (found) {
+ for (i=1; i<=position; i++) {
+ skb = __skb_dequeue(q);
+ zd_mac_tx_status(hw, skb,
+ mac->ack_pending ? mac->ack_signal : 0,
+ i == position ? tx_status : NULL);
+ mac->ack_pending = 0;
+ }
+ }
+
+ spin_unlock_irqrestore(&q->lock, flags);
}

/**
@@ -342,18 +467,27 @@ void zd_mac_tx_to_dev(struct sk_buff *skb, int error)
{
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct ieee80211_hw *hw = info->rate_driver_data[0];
+ struct zd_mac *mac = zd_hw_mac(hw);
+
+ ieee80211_tx_info_clear_status(info);

skb_pull(skb, sizeof(struct zd_ctrlset));
if (unlikely(error ||
(info->flags & IEEE80211_TX_CTL_NO_ACK))) {
- tx_status(hw, skb, 0, !error);
+ /*
+ * FIXME : do we need to fill in anything ?
+ */
+ ieee80211_tx_status_irqsafe(hw, skb);
} else {
- struct sk_buff_head *q =
- &zd_hw_mac(hw)->ack_wait_queue;
+ struct sk_buff_head *q = &mac->ack_wait_queue;

skb_queue_tail(q, skb);
- while (skb_queue_len(q) > ZD_MAC_MAX_ACK_WAITERS)
- zd_mac_tx_failed(hw);
+ while (skb_queue_len(q) > ZD_MAC_MAX_ACK_WAITERS) {
+ zd_mac_tx_status(hw, skb_dequeue(q),
+ mac->ack_pending ? mac->ack_signal : 0,
+ NULL);
+ mac->ack_pending = 0;
+ }
}
}

@@ -606,27 +740,47 @@ fail:
static int filter_ack(struct ieee80211_hw *hw, struct ieee80211_hdr *rx_hdr,
struct ieee80211_rx_status *stats)
{
+ struct zd_mac *mac = zd_hw_mac(hw);
struct sk_buff *skb;
struct sk_buff_head *q;
unsigned long flags;
+ int found = 0;
+ int i, position = 0;

if (!ieee80211_is_ack(rx_hdr->frame_control))
return 0;

- q = &zd_hw_mac(hw)->ack_wait_queue;
+ q = &mac->ack_wait_queue;
spin_lock_irqsave(&q->lock, flags);
skb_queue_walk(q, skb) {
struct ieee80211_hdr *tx_hdr;

+ position ++;
+
+ if (mac->ack_pending && skb_queue_is_first(q, skb))
+ continue;
+
tx_hdr = (struct ieee80211_hdr *)skb->data;
if (likely(!memcmp(tx_hdr->addr2, rx_hdr->addr1, ETH_ALEN)))
{
- __skb_unlink(skb, q);
- tx_status(hw, skb, stats->signal, 1);
- goto out;
+ found = 1;
+ break;
}
}
-out:
+
+ if (found) {
+ for (i=1; i<position; i++) {
+ skb = __skb_dequeue(q);
+ zd_mac_tx_status(hw, skb,
+ mac->ack_pending ? mac->ack_signal : 0,
+ NULL);
+ mac->ack_pending = 0;
+ }
+
+ mac->ack_pending = 1;
+ mac->ack_signal = stats->signal;
+ }
+
spin_unlock_irqrestore(&q->lock, flags);
return 1;
}
@@ -709,6 +863,7 @@ int zd_mac_rx(struct ieee80211_hw *hw, const u8 *buffer, unsigned int length)
skb_reserve(skb, 2);
}

+ /* FIXME : could we avoid this big memcpy ? */
memcpy(skb_put(skb, length), buffer, length);

memcpy(IEEE80211_SKB_RXCB(skb), &stats, sizeof(stats));
@@ -999,7 +1154,14 @@ struct ieee80211_hw *zd_mac_alloc_hw(struct usb_interface *intf)
hw->queues = 1;
hw->extra_tx_headroom = sizeof(struct zd_ctrlset);

+ /*
+ * Tell mac80211 that we support multi rate retries
+ */
+ hw->max_rates = IEEE80211_TX_MAX_RATES;
+ hw->max_rate_tries = 18; /* 9 rates * 2 retries/rate */
+
skb_queue_head_init(&mac->ack_wait_queue);
+ mac->ack_pending = 0;

zd_chip_init(&mac->chip, hw, intf);
housekeeping_init(mac);
diff --git a/drivers/net/wireless/zd1211rw/zd_mac.h b/drivers/net/wireless/zd1211rw/zd_mac.h
index 7c27591..630c298 100644
--- a/drivers/net/wireless/zd1211rw/zd_mac.h
+++ b/drivers/net/wireless/zd1211rw/zd_mac.h
@@ -140,6 +140,21 @@ struct rx_status {
#define ZD_RX_CRC16_ERROR 0x40
#define ZD_RX_ERROR 0x80

+struct tx_retry_rate {
+ int count; /* number of valid element in rate[] array */
+ int rate[10]; /* retry rates, described by an index in zd_rates[] */
+};
+
+struct tx_status {
+ u8 type; /* must always be 0x01 : USB_INT_TYPE */
+ u8 id; /* must always be 0xa0 : USB_INT_ID_RETRY_FAILED */
+ u8 rate;
+ u8 pad;
+ u8 mac[ETH_ALEN];
+ u8 retry;
+ u8 failure;
+} __attribute__((packed));
+
enum mac_flags {
MAC_FIXED_CHANNEL = 0x01,
};
@@ -150,7 +165,7 @@ struct housekeeping {

#define ZD_MAC_STATS_BUFFER_SIZE 16

-#define ZD_MAC_MAX_ACK_WAITERS 10
+#define ZD_MAC_MAX_ACK_WAITERS 50

struct zd_mac {
struct zd_chip chip;
@@ -184,6 +199,12 @@ struct zd_mac {

/* whether to pass control frames to stack */
unsigned int pass_ctrl:1;
+
+ /* whether we have received a 802.11 ACK that is pending */
+ unsigned int ack_pending:1;
+
+ /* signal strength of the last 802.11 ACK received */
+ int ack_signal;
};

#define ZD_REGDOMAIN_FCC 0x10
@@ -279,7 +300,7 @@ int zd_mac_preinit_hw(struct ieee80211_hw *hw);
int zd_mac_init_hw(struct ieee80211_hw *hw);

int zd_mac_rx(struct ieee80211_hw *hw, const u8 *buffer, unsigned int length);
-void zd_mac_tx_failed(struct ieee80211_hw *hw);
+void zd_mac_tx_failed(struct urb *urb);
void zd_mac_tx_to_dev(struct sk_buff *skb, int error);

#ifdef DEBUG
diff --git a/drivers/net/wireless/zd1211rw/zd_usb.c b/drivers/net/wireless/zd1211rw/zd_usb.c
index 3868884..ddfaa73 100644
--- a/drivers/net/wireless/zd1211rw/zd_usb.c
+++ b/drivers/net/wireless/zd1211rw/zd_usb.c
@@ -419,7 +419,7 @@ static void int_urb_complete(struct urb *urb)
handle_regs_int(urb);
break;
case USB_INT_ID_RETRY_FAILED:
- zd_mac_tx_failed(zd_usb_to_hw(urb->context));
+ zd_mac_tx_failed(urb);
break;
default:
dev_dbg_f(urb_dev(urb), "error: urb %p unknown id %x\n", urb,
@@ -553,6 +553,8 @@ static void handle_rx_packet(struct zd_usb *usb, const u8 *buffer,

if (length < sizeof(struct rx_length_info)) {
/* It's not a complete packet anyhow. */
+ printk("%s: invalid, small RX packet : %d\n",
+ __func__, length);
return;
}
length_info = (struct rx_length_info *)
--
1.6.2.4

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs

Re: CR_TOTAL_TX_FRM register

2009-10-10T00:48:49Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Benoit PAPILLAULT a écrit :

> Hello,
>
> I've tried the vendor driver ZD1211LnxDrv_2_22_0_0 and the TotalTxFrm
> register IS updated (using a 2.6.18 kernel this time). So it seems the
> zd1211rw driver is missing something.
>
> How I can help debugging this?
>
> Regards,
> Benoit

Hello,

I found out what's wrong. Each 32 bits register is read using 2 16 bits
read request over the USB bus and since the ZD_RetryCnt is a
read-and-clear register, if we read the wrong 16 bits part first, the
other part is reset. This explain why I was getting always 0.

I'll try to do a patch in the next couple of days for zd_ioread32v_locked.

Regards,
Benoit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrQN6MACgkQOR6EySwP7oIcxACgxK0nzuvso+F2ditw7zRan/Eb
xuEAnj4CUSkoCVci+MZb0gvuX/C3Njkg
=l6cG
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs

Re: CR_TOTAL_TX_FRM register

2009-10-05T14:13:15Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Benoit PAPILLAULT a écrit :

> Hello,
>
> I'm currently trying to understand the Zydas chip (I found out that all
> my machine / servers are using it). I'm trying to learn mac80211 as well
> (I have some experience with ath5k & rt2x00).
>
> Anyway, I tried to read the CR_TOTAL_TX_FRM (see zd_chip.h) and this
> register is always 0, except few times where it is 1. Apparently, this
> register is reset when it is read. However, I need to transfer several
> MB before getting a 1.
>
> Is that normal? How I can debug further?
>
> Regards,
> Benoit

Hello,

I've tried the vendor driver ZD1211LnxDrv_2_22_0_0 and the TotalTxFrm
register IS updated (using a 2.6.18 kernel this time). So it seems the
zd1211rw driver is missing something.

How I can help debugging this?

Regards,
Benoit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrKYWEACgkQOR6EySwP7oIo5QCfXX54ggr5zp3pXuZGGm/MTd+o
d0MAn2ASPRdO3ByYOWHrpIlCO2iK2tAF
=vc1J
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs

CR_TOTAL_TX_FRM register

2009-10-04T13:10:51Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

I'm currently trying to understand the Zydas chip (I found out that all
my machine / servers are using it). I'm trying to learn mac80211 as well
(I have some experience with ath5k & rt2x00).

Anyway, I tried to read the CR_TOTAL_TX_FRM (see zd_chip.h) and this
register is always 0, except few times where it is 1. Apparently, this
register is reset when it is read. However, I need to transfer several
MB before getting a 1.

Is that normal? How I can debug further?

Regards,
Benoit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrJAUgACgkQOR6EySwP7oLPwQCg7i2frZy9pUl7Yw7VFf3YnslD
DYwAnj2Zdm2HEQVziuVcE+RupIUq4yIc
=T/4d
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs

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

2009-08-17T18:44:45Z

--- On Thu, 30/7/09, Hin-Tak Leung <hintak_leung@...> wrote:

> --- On Thu, 30/7/09, Mladen Horvat
> <acid-burn@...>
> 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@...>
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
_______________________________________________
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs

No RSSI in Radiotap header on bleeding edge compat-wireless 2.6

2009-08-12T21:29:11Z

I've just updated to the latest compat-wireless 2.6 and there does not appear to be any RSSI information in the Radiotap Header for incoming packets. Can this be corrected? Previously the driver that came with Ubuntu 9.04 gave an RSSI value but Kismet didn't like it (values from 5 to 103). I've been doing some sensitivity tests with RF attenuators and the RSSI values from the old driver do appear to follow a dB scale.

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

2009-08-08T10:46:31Z

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@...> 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
_______________________________________________
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs

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

2009-08-08T09:56:31Z

--- On Sat, 8/8/09, "Sören Wellhöfer" <Soeren.Wellhoefer@...> 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
_______________________________________________
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs

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

2009-08-08T09:33:42Z

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@...> 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@...>
>
> 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
> > @@ -25,7 +25,7 @@
> >
> > 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?
>
>
>
>

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

2009-08-08T07:25:25Z

--- On Fri, 7/8/09, "Sören Wellhöfer" <Soeren.Wellhoefer@...> 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@...>

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
> @@ -25,7 +25,7 @@
>
> 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
_______________________________________________
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs

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

2009-08-07T09:47:53Z

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@...>

---
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
@@ -2,7 +2,7 @@ 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
@@ -720,6 +720,10 @@ 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
@@ -137,10 +137,14 @@ 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;
}
@@ -156,6 +160,9 @@ 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
@@ -536,9 +536,8 @@ 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)) {
@@ -1195,6 +1194,8 @@ 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
@@ -25,7 +25,7 @@

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",
@@ -52,6 +52,7 @@ 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)
@@ -81,6 +82,12 @@ 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
@@ -47,6 +47,7 @@ struct zd_rf {
u8 type;

u8 channel;
+ void *priv;

/* RF-specific functions */
int (*init_hw)(struct zd_rf *rf);
@@ -54,6 +55,9 @@ 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);
@@ -76,5 +80,6 @@ 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
@@ -0,0 +1,539 @@
+/* ZD1211 USB-WLAN driver for Linux
+ *
+ * Copyright (C) 2005-2007 Ulrich Kunitz <kune@...>
+ * Copyright (C) 2006-2007 Daniel Drake <dsd@...>
+ *
+ * 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
_______________________________________________
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs

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

2009-08-05T13:31:49Z

On Wed, Aug 5, 2009 at 7:59 PM, Genar Codina
Reverter<genarcodina@...> 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
_______________________________________________
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs

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

2009-08-05T10:59:38Z

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
_______________________________________________
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs

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

2009-07-30T07:19:40Z

--- On Thu, 30/7/09, Mladen Horvat <acid-burn@...> wrote:

> Using the offical 2.6.30 kernel from kernel.org:
> www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.30.tar.bz2

Hmm, I have that as well, and the patches I used are those I mentioned... Hmm, did you copy over any compat-wireless headers? Those are beyond 2.6.31.

> what does not look great is this stuff:
>
> [ 6133.287000] wrq->u.param.value = 00000000
> [ 6133.301000] Temp Solution here. Need to look detail
> [ 6133.525000] 1211_readl failed for 5 attempts...Very
> Serious<3>1211_readl
> failed for 5 attempts...Very Serious<3>1211_readl
> failed for 5 attempts...Very
> Serious<3>1211_readl failed for 5 attempts...Very
> Serious<3>1211_readl failed
> for 5 attempts...Very Serious<3>1211_readl failed for
> 5 attempts...Very
> Serious<3>1211_readl failed for 5 attempts...Very
> Serious<3>1211_readl failed
> for 5 attempts...Very Serious<3>1211_readl failed for
> 5 attempts...Very
> Serious<3>1211_readl failed for 5 attempts...Very
> SeriousgetService failed!
> getService failed!

This comes from one of my patches to cope with slow CPUs. I haven't seen them with 3.0 (used to see them in 2.22) - so 3.0 had coped some other way. They are fairly harmless actually, you could increase the 5 if your board is really slow.

> Scanning works here but no connect to my hidden Network
> with wpa2.
> perhaps there is only a patch missing on the ssid stuff i
> saw somewhere for
> zd1211rw

Well, nobody has done anything significant for the rw driver for a year or two now. (other than just adding ids and the odd change to cope with changes elsewhere in the kernel). good luck fixing that or the firmware load problem. If you manage anything, please write back.

------------------------------------------------------------------------------
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
_______________________________________________
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs

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

2009-07-30T07:04:34Z

Hin-Tak Leung <hintak_leung <at> yahoo.co.uk> writes:

>
> 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)

Using the offical 2.6.30 kernel from kernel.org:
www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.30.tar.bz2

> > But: looks like the driver doesnt work or like my
> > WPA-Supplicant 0.6.9
> >
> > Here is a Bootlog and outputs that come: http://pastebin.com/m232e0dfa
>
> The log looks okay to me... sorry I only use it in AP mode & with WEP,can't
help you there.

what does not look great is this stuff:

[ 6133.287000] wrq->u.param.value = 00000000
[ 6133.301000] Temp Solution here. Need to look detail
[ 6133.525000] 1211_readl failed for 5 attempts...Very Serious<3>1211_readl
failed for 5 attempts...Very Serious<3>1211_readl failed for 5 attempts...Very
Serious<3>1211_readl failed for 5 attempts...Very Serious<3>1211_readl failed
for 5 attempts...Very Serious<3>1211_readl failed for 5 attempts...Very
Serious<3>1211_readl failed for 5 attempts...Very Serious<3>1211_readl failed
for 5 attempts...Very Serious<3>1211_readl failed for 5 attempts...Very
Serious<3>1211_readl failed for 5 attempts...Very SeriousgetService failed!
getService failed!

>
> I did find the driver in AP mode has a curious behavior: it won't talk to a
client after loading until I do
> something like 'iwlist scan' or 'iwpriv card_reset' first. (the latter hangs
the machine 1/2 of the time,
> but iwlist scan is quite reliable and I only need to do it once per reboot of
the AP which isn't bad). May be you
> can try iwlist scan as a client also.
>

Scanning works here but no connect to my hidden Network with wpa2.
perhaps there is only a patch missing on the ssid stuff i saw somewhere for
zd1211rw

here some output:
State: DISCONNECTED -> SCANNING
Starting AP scan (specific SSID)
Scan SSID - hexdump_ascii(len=8):
53 70 61 63 65 4e 65 74 MyNet
CTRL-EVENT-SCAN-RESULTS
Selecting BSS from priority group 0
Try to find WPA-enabled AP
Try to find non-WPA AP
0: 00:15:0c:85:06:66 ssid='' wpa_ie_len=0 rsn_ie_len=20 caps=0x11
skip - SSID mismatch
^^ this is my AP with hidden ssid but even with non hidden there is no
connection possible.

So i probably think it would be best to somehow fix the firmwareloading in
zd1211rw probaly.

regards

------------------------------------------------------------------------------
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
_______________________________________________
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs

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

2009-07-30T06:27:33Z

--- On Thu, 30/7/09, Mladen Horvat <acid-burn@...> 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)

> Firmware Upload works !!! and interface comes up as
> ath0.

Yes, the renaming is a visible change.

>
> But: looks like the driver doesnt work or like my
> WPA-Supplicant 0.6.9
>
> Here is a Bootlog and outputs that come: http://pastebin.com/m232e0dfa

The log looks okay to me... sorry I only use it in AP mode & with WEP, can't help you there.

I did find the driver in AP mode has a curious behavior: it won't talk to a client after loading until I do something like 'iwlist scan' or 'iwpriv card_reset' first. (the latter hangs the machine 1/2 of the time, but iwlist scan is quite reliable and I only need to do it once per reboot of the AP which isn't bad). May be you can try iwlist scan as a client also.

------------------------------------------------------------------------------
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
_______________________________________________
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs

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

2009-07-30T05:15:13Z

Hin-Tak Leung <hintak_leung <at> yahoo.co.uk> writes:

> Well, if the vendor driver 2.22.00 works with 2.6.12, you can grab my patch
set (sorry it is 'pathset' in the
> web location - I made a mistake in May and haven't fixed it yet):
> http://htl10.users.sourceforge.net/ZD1211LnxDrv_2_22_0_0_2009May_pathset/
>
> which would take you up to 2.6.29. I haven't tried 2.6.30 as I already moved
to the vendor driver 3.0 by then.
> You need the other patch set
>
> http://htl10.users.sourceforge.net/LinuxUSB_AR2524-3.0.0.56_2009May_pathset/
> to take you up to 2.6.29, and the last one (attached) to take you to 2.6.30..
It may also work for the 2.22
> driver but I haven't tried, but it will at least give you some ideas if you
like to make the vendor 2.22 driver
> work on 2.6.30.
>
> The 3.0 vendor driver is at:
>
http://www.kernel.org/pub/linux/kernel/people/mcgrof/zd1211/LinuxUSB_AR2524-3.0.0.56.tgz
>
> Hmm, the firmware upload problem seems to have come up from time to time...
>
> if either versions of the vendor drivers work (but the rw driver does not) I
like to know. You will need to set
> up the blacklist to stop udev from autoloading kernel modules, but presumably
you already know that.
>

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

Firmware Upload works !!! and interface comes up as ath0.

But: looks like the driver doesnt work or like my WPA-Supplicant 0.6.9

Here is a Bootlog and outputs that come: http://pastebin.com/m232e0dfa

Network Configuration:
cat /etc/network/interfaces
auto ath0
iface ath0 inet dhcp
wpa-driver wext
wpa-debug-level 3
wpa-conf /etc/wpa_supplicant.conf

auto eth0
iface eth0 inet dhcp

cat /etc/wpa_supplicant.conf
ctrl_interface=/var/run/wpa_supplicant
eapol_version=1
fast_reauth=1
ap_scan=1
network={
ssid="MyNetwork"
scan_ssid=1
key_mgmt=WPA-PSK
proto=WPA RSN
pairwise=CCMP TKIP
group=CCMP TKIP
psk="MyPassword"
}

This configuration works flawless with an other machine and a ath5k mini-pci
card or on the same machine with an rt73usb stick running wpa-supplicant 0.6.9
and the wext driver.

Any Idea ?

regards

Mladen

------------------------------------------------------------------------------
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
_______________________________________________
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs

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

2009-07-30T01:39:21Z

Do not write directly - all traffic should go into the mailing list archive.. That's very selfish behavior. I do not work for you and I'll have to charge you on private consultancy rate for that.

Your kernel headers do not match your kernel. (supposedly 2.6.30), nothing to do with
compiler version.

--- On Thu, 30/7/09, acid-burn <acid-burn@...> wrote:

> Hello,
>
> thought i write you directlyand not bother the list with
> compile problems..
>
> i am currently trying to compile the 3.0 src with your
> patches.
>
> I get a bunch of warnings about undefined things and
> errors.
>
> Could this be related on the used gcc compiler ?
>
> I have to use gcc-4.4.0
>
>
> Perhaps you have an idea ?
>
> Regards
>
> Mladen

------------------------------------------------------------------------------
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
_______________________________________________
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs

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

2009-07-29T08:27:51Z

--- On Wed, 29/7/09, Mladen Horvat <acid-burn@...> wrote:

> Hi again,
>
> perhaps this is an idea to try the vendor 3.0 driver with
> the new kernel.
>
> Just a question. Is the driver using the new mac80211
> wireless interface so i
> can use it over wpa supllicant 0.6.9 and the build-in wext
> interface ?
>
> Just saw sth about wpa-s 0.4.8 and was wondering if this
> will work ?

old stack, but it does wext and should just work regardless of wpa supplicant version.
(I don't use that - I run it in AP mode). Basically whatever you did with 2..22 should just work with 3.0 - only better and less buggy :-).

------------------------------------------------------------------------------
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
_______________________________________________
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs

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

2009-07-29T07:59:20Z

Hin-Tak Leung <hintak_leung <at> yahoo.co.uk> writes:

>
> --- On Wed, 29/7/09, Mladen Horvat <acid-burn <at> opendreambox.org> wrote:
>
> > Hi Hin-Tak
> >
> > thanks for your fast answer.
> >
> > The same stb only booted with a rt73usb wlan stick attached
> > has no
> > problems with the firmware upload and also wpa-supplicant
> > connection and
> > everything works on wlan0. only problem are these two
> > zd1211b usb sticks in the
> > zd1211rw driver i have here.
> >
> > the same stb running a kernel 2.6.12 and the original
> > vendor driver 2.22.00
> > works without problems..
> >
> > i will take a look what happens with an externally powered
> > usb hub.
> >
> > Hope this helps.
> > If any other logs are needed i will provide them.
>
> Well, if the vendor driver 2.22.00 works with 2.6.12, you can grab my patch

set (sorry it is 'pathset' in the
> web location - I made a mistake in May and haven't fixed it yet):
> http://htl10.users.sourceforge.net/ZD1211LnxDrv_2_22_0_0_2009May_pathset/
>
> which would take you up to 2.6.29. I haven't tried 2.6.30 as I already moved
to the vendor driver 3.0 by then.
> You need the other patch set
>
> http://htl10.users.sourceforge.net/LinuxUSB_AR2524-3.0.0.56_2009May_pathset/
> to take you up to 2.6.29, and the last one (attached) to take you to 2.6.30..
It may also work for the 2.22
> driver but I haven't tried, but it will at least give you some ideas if you
like to make the vendor 2.22 driver
> work on 2.6.30.
>
> The 3.0 vendor driver is at:
>
http://www.kernel.org/pub/linux/kernel/people/mcgrof/zd1211/LinuxUSB_AR2524-3.0.0.56.tgz
>
> Hmm, the firmware upload problem seems to have come up from time to time...
>
> if either versions of the vendor drivers work (but the rw driver does not) I
like to know. You will need to set
> up the blacklist to stop udev from autoloading kernel modules, but presumably
you already know that.
>
>
> Attachment (0001-2.6.30-irqreturn_t-breakage.patch): text/x-patch, 1020 bytes
>

Hi again,

perhaps this is an idea to try the vendor 3.0 driver with the new kernel.

Just a question. Is the driver using the new mac80211 wireless interface so i
can use it over wpa supllicant 0.6.9 and the build-in wext interface ?

Just saw sth about wpa-s 0.4.8 and was wondering if this will work ?

regards

Mladen

------------------------------------------------------------------------------
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
_______________________________________________
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs

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

2009-07-29T07:30:02Z

--- On Wed, 29/7/09, Mladen Horvat <acid-burn@...> wrote:

> Hi Hin-Tak
>
> thanks for your fast answer.
>
> The same stb only booted with a rt73usb wlan stick attached
> has no
> problems with the firmware upload and also wpa-supplicant
> connection and
> everything works on wlan0. only problem are these two
> zd1211b usb sticks in the
> zd1211rw driver i have here.
>
> the same stb running a kernel 2.6.12 and the original
> vendor driver 2.22.00
> works without problems..
>
> i will take a look what happens with an externally powered
> usb hub.
>
> Hope this helps.
> If any other logs are needed i will provide them.

Well, if the vendor driver 2.22.00 works with 2.6.12, you can grab my patch set (sorry it is 'pathset' in the web location - I made a mistake in May and haven't fixed it yet): http://htl10.users.sourceforge.net/ZD1211LnxDrv_2_22_0_0_2009May_pathset/

which would take you up to 2.6.29. I haven't tried 2.6.30 as I already moved to the vendor driver 3.0 by then. You need the other patch set

http://htl10.users.sourceforge.net/LinuxUSB_AR2524-3.0.0.56_2009May_pathset/
to take you up to 2.6.29, and the last one (attached) to take you to 2.6.30.. It may also work for the 2.22 driver but I haven't tried, but it will at least give you some ideas if you like to make the vendor 2.22 driver work on 2.6.30.

The 3.0 vendor driver is at:
http://www.kernel.org/pub/linux/kernel/people/mcgrof/zd1211/LinuxUSB_AR2524-3.0.0.56.tgz

Hmm, the firmware upload problem seems to have come up from time to time...

if either versions of the vendor drivers work (but the rw driver does not) I like to know. You will need to set up the blacklist to stop udev from autoloading kernel modules, but presumably you already know that.

[0001-2.6.30-irqreturn_t-breakage.patch]

From 470a784d9ba4db962fb66080bdf2ca0d1d2edc9e Mon Sep 17 00:00:00 2001 From: Hin-Tak Leung <HinTak.Leung@...> Date: Thu, 25 Jun 2009 00:09:08 +0100 Subject: [PATCH] 2.6.30-irqreturn_t-breakage Change to deal with this change: commit bedd30d986a05e32dc3eab874e4b9ed8a38058bb Author: Thomas Gleixner <tglx@...> Date: Tue Sep 30 23:14:27 2008 +0200 genirq: make irqreturn_t an enum Impact: cleanup Remove the 2.4 compabiliy cruft Signed-off-by: Thomas Gleixner <tglx@...> Reviewed-by: Peter Zijlstra <peterz@...> --- ar2524drv/src/zdcompat.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/ar2524drv/src/zdcompat.h b/ar2524drv/src/zdcompat.h index 3d352e7..45008ba 100644 --- a/ar2524drv/src/zdcompat.h +++ b/ar2524drv/src/zdcompat.h @@ -65,7 +65,7 @@ struct iw_request_info #endif /* linux < 2.5.69 */ -#ifndef IRQ_NONE +#ifndef _LINUX_IRQRETURN_H typedef void irqreturn_t; #define IRQ_NONE #define IRQ_HANDLED -- 1.6.2.5

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

2009-07-29T07:20:07Z

Hin-Tak Leung <hintak_leung <at> yahoo.co.uk> writes:

>
> -145 is time out ('Use the source, Luke!'). mips is a bit exotic, not many
people have that, and probably not
> very well-tested; could try compat-wireless to see if there is any endian
fixes. The other thing is, ohci
> is a bit slow, and the ZyDAS chip draws a fair amount of power and doesn't
really work on bus-powered usb 1.1
> host, if that's what you have. I don't know if you would get a 'not enough
power' message - I seem to recall I
> did.
>

Ok. Just added a external usb hub but now there are even more errors ;-)
http://pastebin.com/m37023ceb
perhaps it helps.

regards

Mladen

------------------------------------------------------------------------------
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
_______________________________________________
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs

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

2009-07-29T06:53:58Z

Hin-Tak Leung <hintak_leung <at> yahoo.co.uk> writes:

>
> -145 is time out ('Use the source, Luke!'). mips is a bit exotic, not many
people have that, and probably not
> very well-tested; could try compat-wireless to see if there is any endian
fixes. The other thing is, ohci
> is a bit slow, and the ZyDAS chip draws a fair amount of power and doesn't
really work on bus-powered usb 1.1
> host, if that's what you have. I don't know if you would get a 'not enough
power' message - I seem to recall I
> did.
>

Hi Hin-Tak

thanks for your fast answer.

The same stb only booted with a rt73usb wlan stick attached has no
problems with the firmware upload and also wpa-supplicant connection and
everything works on wlan0. only problem are these two zd1211b usb sticks in the
zd1211rw driver i have here.

the same stb running a kernel 2.6.12 and the original vendor driver 2.22.00
works without problems..

i will take a look what happens with an externally powered usb hub.

Hope this helps.
If any other logs are needed i will provide them.

Regards

Mladen

------------------------------------------------------------------------------
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
_______________________________________________
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs

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

2009-07-29T06:39:29Z

-145 is time out ('Use the source, Luke!'). mips is a bit exotic, not many people have that, and probably not very well-tested; could try compat-wireless to see if there is any endian fixes. The other thing is, ohci is a bit slow, and the ZyDAS chip draws a fair amount of power and doesn't really work on bus-powered usb 1.1 host, if that's what you have. I don't know if you would get a 'not enough power' message - I seem to recall I did.

--- On Wed, 29/7/09, Mladen Horvat <acid-burn@...> wrote:

> From: Mladen Horvat <acid-burn@...>
> Subject: [zd1211-devs] zd1211rw couldn't load firmware. Error number -145 with Kernel 2.6.30
> To: zd1211-devs@...
> Date: Wednesday, 29 July, 2009, 12:32 PM
> Hello all,
>
> i am running Kernel 2.6.30 on a embedded linux stb and
> trying with two
> different zd1211b usb wlan sticks to get the zd1211rw
> driver running.
>
> just as a remark: an rt73usb stick works without
> problems.
>
> Dont know what you need. so here is some informations:
>
> uname -a
> Linux dm7025 2.6.30-dm7025 #1 Tue Jul 28 20:25:28 CEST 2009
> mips unknown
>
> lsmod
> Tainted: P
> arc4 1536 2 - Live 0xc05c5000
> ecb 2880 2 - Live 0xc05bc000
> cryptomgr 87872 0 - Live 0xc059d000
> crypto_hash 11840 1 cryptomgr, Live 0xc057a000
> crypto_blkcipher 13232 2 ecb,cryptomgr, Live 0xc056c000
> aead 7168 1 cryptomgr, Live 0xc0560000
> pcompress 1952 1 cryptomgr, Live 0xc0558000
> crypto_algapi 18176 7
> arc4,ecb,cryptomgr,crypto_hash,crypto_blkcipher,aead,pcompress,
> Live 0xc054a000
> zd1211rw 78736 0 - Live 0xc0527000
> mac80211 174976 1 zd1211rw, Live 0xc04d6000
> crypto 13360 8
> ecb,cryptomgr,crypto_hash,crypto_blkcipher,aead,pcompress,crypto_algapi,
> mac80211, Live
> 0xc048c000
> cfg80211 79216 2 zd1211rw,mac80211, Live 0xc046e000
> rfmod 3808 1 - Live 0xc0448000 (P)
> dreambox_keyboard 5248 0 - Live 0xc043d000 (P)
> dreambox_rc2 5248 1 dreambox_keyboard, Live 0xc0431000 (P)
> xilleon 222592 6 - Live 0xc0185000 (P)
> alps_bsbe1_c01a 19568 1 xilleon, Live 0xc0132000 (P)
> alps_bsbe1 5264 1 xilleon, Live 0xc0124000 (P)
> avs 11168 1 xilleon, Live 0xc0117000 (P)
> alps_bsbe2 44480 1 xilleon, Live 0xc0103000 (P)
> lnb_ctrl 5664 3 alps_bsbe1_c01a,alps_bsbe1,alps_bsbe2, Live
> 0xc00f0000 (P)
> tu1216 44912 1 xilleon, Live 0xc00de000
> cu1216mk3 9504 1 xilleon, Live 0xc00c9000 (P)
> stb_core 52704 10
> dreambox_keyboard,dreambox_rc2,xilleon,alps_bsbe1_c01a,avs,alps_bsbe2,
> lnb_ctrl,cu1216mk3,
> Live 0xc00b1000 (P)
> pata_xilleon 3888 1 - Live 0xc0095000
> lcd 30800 1 - Live 0xc0084000 (P)
> fp 21840 4 xilleon,avs,lcd, Live 0xc0072000 (P)
>
> Output from DMESG:
> [ 279.131000] cfg80211: Calling CRDA to update world
> regulatory domain
> [ 279.509000] zd1211rw usb_init()
> [ 279.520000] usbcore: registered new interface
> driver zd1211rw
> [ 279.526000] zd1211rw initialized
> [ 292.405000] usb 1-1: new full speed USB device
> using ohci_hcd
> and address 2
> [ 292.557000] usb 1-1: configuration #1 chosen from 1
> choice
> [ 292.573000] usb 1-1: print_id() 050d:705c v4810
> full
> [ 292.686000] usb 1-1: reset full speed USB device
> using ohci_hcd
> and address 2
> [ 292.829000] zd1211rw 1-1:1.0:
> zd_chip_read_mac_addr_fw()
> [ 293.308000] phy0: Selected rate control algorithm
> 'pid'
> [ 293.309000] zd1211rw 1-1:1.0: probe() successful
> [ 293.309000] zd1211rw 1-1:1.0: phy0
> [ 359.661000] warning: `vsftpd' uses 32-bit
> capabilities (legacy support in use)
> [ 408.957000] zd1211rw 1-1:1.0: zd_usb_init_hw()
> [ 408.957000] usb 1-1: request_fw_file() fw name
> zd1211/zd1211b_ub
> [ 408.957000] usb 1-1: firmware: requesting
> zd1211/zd1211b_ub
> [ 409.022000] usb 1-1: upload_firmware() firmware
> device id 0x4810 is equal
> to
> the actual device id
> [ 409.022000] usb 1-1: request_fw_file() fw name
> zd1211/zd1211b_uphr
> [ 409.022000] usb 1-1: firmware: requesting
> zd1211/zd1211b_uphr
> [ 409.079000] usb 1-1: upload_code() transfer size
> 4018
> [ 409.094000] usb 1-1: upload_code() firmware confirm
> return value 0x01
> [ 414.094000] zd1211rw 1-1:1.0: zd_usb_init_hw()
> couldn't reset configuration. Error number -145
> [ 415.226000] zd1211rw 1-1:1.0: zd_usb_init_hw()
> [ 415.226000] usb 1-1: request_fw_file() fw name
> zd1211/zd1211b_ub
> [ 415.226000] usb 1-1: firmware: requesting
> zd1211/zd1211b_ub
> [ 415.271000] usb 1-1: upload_firmware()
> firmware device id 0x4810 is equal to the actual device id
> [ 415.271000] usb 1-1: request_fw_file() fw name
> zd1211/zd1211b_uphr
> [ 415.271000] usb 1-1: firmware: requesting
> zd1211/zd1211b_uphr
> [ 415.350000] usb 1-1: upload_code() transfer size
> 4018
> [ 416.350000] usb 1-1: USB control request for
> firmware upload failed.
> Error number -145
> [ 416.358000] usb 1-1: Could not upload firmware code
> uph. Error number -145
> [ 416.365000] zd1211rw 1-1:1.0: couldn't load
> firmware. Error number -145
> [ 432.484000] zd1211rw 1-1:1.0: zd_usb_init_hw()
> [ 432.484000] usb 1-1: request_fw_file() fw name
> zd1211/zd1211b_ub
> [ 432.484000] usb 1-1: firmware: requesting
> zd1211/zd1211b_ub
> [ 432.529000] usb 1-1: upload_firmware()
> firmware device id 0x4810 is equal to the actual device id
> [ 432.529000] usb 1-1: request_fw_file() fw name
> zd1211/zd1211b_uphr
> [ 432.529000] usb 1-1: firmware: requesting
> zd1211/zd1211b_uphr
> [ 432.608000] usb 1-1: upload_code() transfer size
> 4018
> [ 433.608000] usb 1-1: USB control request for
> firmware upload failed.
> Error number -145
> [ 433.616000] usb 1-1: Could not upload firmware code
> uph. Error number -145
> [ 433.623000] zd1211rw 1-1:1.0: couldn't load
> firmware. Error number -145
> [ 434.827000] eth0: link up, 100Mbps, full-duplex,
> lpa 0xC5E1
>
> output from lsusb
> Bus 001 Device 002: ID 050d:705c Belkin Components
>
> the Firmware Files are located with correct right under
> /lib/firmware/zd1211
> any idea on this ?
>
> Regards
>
> Mladen
>
>
>
> ------------------------------------------------------------------------------
> 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
> _______________________________________________
> Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
> Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs
>

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

2009-07-29T04:32:38Z

Hello all,

i am running Kernel 2.6.30 on a embedded linux stb and trying with two
different zd1211b usb wlan sticks to get the zd1211rw driver running.

just as a remark: an rt73usb stick works without problems.

Dont know what you need. so here is some informations:

uname -a
Linux dm7025 2.6.30-dm7025 #1 Tue Jul 28 20:25:28 CEST 2009 mips unknown

lsmod
Tainted: P
arc4 1536 2 - Live 0xc05c5000
ecb 2880 2 - Live 0xc05bc000
cryptomgr 87872 0 - Live 0xc059d000
crypto_hash 11840 1 cryptomgr, Live 0xc057a000
crypto_blkcipher 13232 2 ecb,cryptomgr, Live 0xc056c000
aead 7168 1 cryptomgr, Live 0xc0560000
pcompress 1952 1 cryptomgr, Live 0xc0558000
crypto_algapi 18176 7
arc4,ecb,cryptomgr,crypto_hash,crypto_blkcipher,aead,pcompress, Live 0xc054a000
zd1211rw 78736 0 - Live 0xc0527000
mac80211 174976 1 zd1211rw, Live 0xc04d6000
crypto 13360 8
ecb,cryptomgr,crypto_hash,crypto_blkcipher,aead,pcompress,crypto_algapi,
mac80211, Live
0xc048c000
cfg80211 79216 2 zd1211rw,mac80211, Live 0xc046e000
rfmod 3808 1 - Live 0xc0448000 (P)
dreambox_keyboard 5248 0 - Live 0xc043d000 (P)
dreambox_rc2 5248 1 dreambox_keyboard, Live 0xc0431000 (P)
xilleon 222592 6 - Live 0xc0185000 (P)
alps_bsbe1_c01a 19568 1 xilleon, Live 0xc0132000 (P)
alps_bsbe1 5264 1 xilleon, Live 0xc0124000 (P)
avs 11168 1 xilleon, Live 0xc0117000 (P)
alps_bsbe2 44480 1 xilleon, Live 0xc0103000 (P)
lnb_ctrl 5664 3 alps_bsbe1_c01a,alps_bsbe1,alps_bsbe2, Live 0xc00f0000 (P)
tu1216 44912 1 xilleon, Live 0xc00de000
cu1216mk3 9504 1 xilleon, Live 0xc00c9000 (P)
stb_core 52704 10
dreambox_keyboard,dreambox_rc2,xilleon,alps_bsbe1_c01a,avs,alps_bsbe2,
lnb_ctrl,cu1216mk3,
Live 0xc00b1000 (P)
pata_xilleon 3888 1 - Live 0xc0095000
lcd 30800 1 - Live 0xc0084000 (P)
fp 21840 4 xilleon,avs,lcd, Live 0xc0072000 (P)

Output from DMESG:
[ 279.131000] cfg80211: Calling CRDA to update world regulatory domain
[ 279.509000] zd1211rw usb_init()
[ 279.520000] usbcore: registered new interface driver zd1211rw
[ 279.526000] zd1211rw initialized
[ 292.405000] usb 1-1: new full speed USB device using ohci_hcd
and address 2
[ 292.557000] usb 1-1: configuration #1 chosen from 1 choice
[ 292.573000] usb 1-1: print_id() 050d:705c v4810 full
[ 292.686000] usb 1-1: reset full speed USB device using ohci_hcd
and address 2
[ 292.829000] zd1211rw 1-1:1.0: zd_chip_read_mac_addr_fw()
[ 293.308000] phy0: Selected rate control algorithm 'pid'
[ 293.309000] zd1211rw 1-1:1.0: probe() successful
[ 293.309000] zd1211rw 1-1:1.0: phy0
[ 359.661000] warning: `vsftpd' uses 32-bit capabilities (legacy support in use)
[ 408.957000] zd1211rw 1-1:1.0: zd_usb_init_hw()
[ 408.957000] usb 1-1: request_fw_file() fw name zd1211/zd1211b_ub
[ 408.957000] usb 1-1: firmware: requesting zd1211/zd1211b_ub
[ 409.022000] usb 1-1: upload_firmware() firmware device id 0x4810 is equal
to
the actual device id
[ 409.022000] usb 1-1: request_fw_file() fw name zd1211/zd1211b_uphr
[ 409.022000] usb 1-1: firmware: requesting zd1211/zd1211b_uphr
[ 409.079000] usb 1-1: upload_code() transfer size 4018
[ 409.094000] usb 1-1: upload_code() firmware confirm return value 0x01
[ 414.094000] zd1211rw 1-1:1.0: zd_usb_init_hw()
couldn't reset configuration. Error number -145
[ 415.226000] zd1211rw 1-1:1.0: zd_usb_init_hw()
[ 415.226000] usb 1-1: request_fw_file() fw name zd1211/zd1211b_ub
[ 415.226000] usb 1-1: firmware: requesting zd1211/zd1211b_ub
[ 415.271000] usb 1-1: upload_firmware()
firmware device id 0x4810 is equal to the actual device id
[ 415.271000] usb 1-1: request_fw_file() fw name zd1211/zd1211b_uphr
[ 415.271000] usb 1-1: firmware: requesting zd1211/zd1211b_uphr
[ 415.350000] usb 1-1: upload_code() transfer size 4018
[ 416.350000] usb 1-1: USB control request for firmware upload failed.
Error number -145
[ 416.358000] usb 1-1: Could not upload firmware code uph. Error number -145
[ 416.365000] zd1211rw 1-1:1.0: couldn't load firmware. Error number -145
[ 432.484000] zd1211rw 1-1:1.0: zd_usb_init_hw()
[ 432.484000] usb 1-1: request_fw_file() fw name zd1211/zd1211b_ub
[ 432.484000] usb 1-1: firmware: requesting zd1211/zd1211b_ub
[ 432.529000] usb 1-1: upload_firmware()
firmware device id 0x4810 is equal to the actual device id
[ 432.529000] usb 1-1: request_fw_file() fw name zd1211/zd1211b_uphr
[ 432.529000] usb 1-1: firmware: requesting zd1211/zd1211b_uphr
[ 432.608000] usb 1-1: upload_code() transfer size 4018
[ 433.608000] usb 1-1: USB control request for firmware upload failed.
Error number -145
[ 433.616000] usb 1-1: Could not upload firmware code uph. Error number -145
[ 433.623000] zd1211rw 1-1:1.0: couldn't load firmware. Error number -145
[ 434.827000] eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1

output from lsusb
Bus 001 Device 002: ID 050d:705c Belkin Components

the Firmware Files are located with correct right under /lib/firmware/zd1211
any idea on this ?

Regards

Mladen

------------------------------------------------------------------------------
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
_______________________________________________
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs

zd1211rw successfully tested on "SONY IFU-WLM2"

2009-06-25T01:08:20Z

Hi there.

I've successfully tested zd1211rw driver (compat-wireless-2.6-old) on

Brand/retail: SONY IFU-WLM2
USB-IDs: Vendor: 0x054C Device: 0x0257
chip ID: zd1211b chip 054c:0257 v4802 high 00-0b-6b AL2230_RF pa0 -----
FCC ID: unknown

Thanks for your job.

------------------------------------------------------------------------------
_______________________________________________
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs

Re: Latest version of zd1211b and its latest firmware

2009-06-23T17:27:02Z

--- On Tue, 23/6/09, Nazim Khan <nazim.asad@...> wrote:

> Hi Hin,
>
> Thanks for the info.
>
> So far my 2.22 driver is working fine except one problem
> that under
> stress I get AP loss
> (did not receive the beacon in the 5 seconds).
>
> I was hoping that this issue may get fixed with the latest
> driver
> version but even 3.0.0.56 gave me the same
> problem. I did not check your patch changes though.
>
> I had same issue with 2.18 version also. I tested on PC as
> well as on
> my ARM based board but everywhere
> I get the same problem.

Next to the newer patchset is a similiar set for the older 2_22 at:
ZD1211LnxDrv_2_22_0_0_2009May_pathset

(sorry I just realized I misspelled patchset during the upload for both!) I didn't want to advertise the older set since 2.22 itself is considered obsolete. As in 3.0, some of them are for porting to newer kernels, some are bug fixes, some are cosmetic, but the headers or even the name of each patch would say what each one does. The separation of patches for different purposes are less clear cut in the 2.22 series - or rather, after patching the 2.22 by trial and error, when I was porting 3.0 to newer kernels, etc, I did it more cleanly.

------------------------------------------------------------------------------
_______________________________________________
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs

Re: Latest version of zd1211b and its latest firmware

2009-06-22T23:04:12Z

--- On Tue, 23/6/09, Nazim Khan <nazim.asad@...> wrote:

> Looks like in 3.0.0.56 firmware is added as header files,
> compared to
> firmware upload from user space as it used to be in 2.22.

rw driver has them from user space, the vendor driver has always have them in header files.

> Does you patches contains fix for moving to recent kernel
> or does it
> have any issue/problem fixes also ?

Both - there are about 7-8 parts, 2 or 3 of them move you to recent kernels, there is a big fix I think, and a couple of cosmetic things (e.g. cut down on too many messages). See the individual git log headers.

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs

Re: Latest version of zd1211b and its latest firmware

2009-06-22T22:28:27Z

Hi Hin,

Thanks for your quick response.
I am using Vendor driver and rw driver because my platform is based on
2.6.18 and I believe rewritten driver got added in the kernel
in 2.6.21 or somewhere there.

Looks like in 3.0.0.56 firmware is added as header files, compared to
firmware upload from user space as it used to be in 2.22.

Does you patches contains fix for moving to recent kernel or does it
have any issue/problem fixes also ?

Thanks and regards,
Nazim Khan

On Mon, Jun 22, 2009 at 8:06 PM, Hin-Tak
Leung<htl10@...> wrote:

>
> 3.0 was hosted on the kernel web site.
> http://www.kernel.org/pub/linux/kernel/people/mcgrof/zd1211/
>
> You might want to get my patch sets if you want to run 3.0 on more recent kernels than 2.6.26(?).
> http://htl10.users.sourceforge.net/LinuxUSB_AR2524-3.0.0.56_2009May_pathset/
>
> The in-kernel rw driver works quite well so unless you want AP mode or antenna affinity, you probably should just use the rw driver.
>
>
>
>
>

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs

Re: Latest version of zd1211b and its latest firmware

2009-06-22T07:36:57Z

3.0 was hosted on the kernel web site.
http://www.kernel.org/pub/linux/kernel/people/mcgrof/zd1211/

You might want to get my patch sets if you want to run 3.0 on more recent kernels than 2.6.26(?).
http://htl10.users.sourceforge.net/LinuxUSB_AR2524-3.0.0.56_2009May_pathset/

The in-kernel rw driver works quite well so unless you want AP mode or antenna affinity, you probably should just use the rw driver.

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs

Latest version of zd1211b and its latest firmware

2009-06-22T06:45:45Z

Hi,

Currently I am using Vendor driver version 2.22 and firmware version
1.4 for zd1211b chipset.
Is there any latest version of this driver available?

I read in the mailing list someone mentioning vendor driver 3.0 but
could not find it anywhere on net.

Thanks and regards,
Nazim Khan

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs

Zd1211rw successfully testet on "Arcor Easy Stick A 50 WLAN"

2009-06-12T16:27:24Z

Hi,

I'm using the zd1211rw driver (compat-wireless-2.6.30) successful on
"Arcor Easy Stick A 50 WLAN" (device manufactured by SMC for a German
ISP - SMC model name: WN4501H-LF-IR). General information and Windows
driver are available under

http://www.arcor.de/hilfe/neu/index.php?sid=&aktion=anzeigen&rubrik=004018140&id=487

(German only).

Device details:

USB-IDs: Vendor: 0x083A Device: 0xE503
Chip ID: zd1211b chip 083a:e503 v4810 high 00-1d-19 AL2230S_RF pa0 g--N-

Data throughput is higher than under Windows.

Great job, thanks a lot!

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs