Nabble - ZyDAS ZD1211 Linux Driver

Re: monitor mode not capturing other BSS packets

2009-11-26T01:47:14Z

2009/11/25 Benoit PAPILLAULT <benoit.papillault@...>:

> Benoit PAPILLAULT a écrit :
>>
>> TX rate is dropping a lot (like 20 MBits down to 200 kbits/s). Using
>> another card in monitor mode, I still see packets sent at 54 Mbits rate
>> however.
>>
>>
>
> I found out what is wrong with the TX throughput. In fact, when a packet is
> transmitted at 54 Mbits, the destination send back a 802.11 ACK which is
> ignored!!! As such, the packet is transmitted at 54 Mbits once again, then
> twice at 48 Mbits, then twice at 36 Mbits ... and so on down to 1 Mbits. Of
> course, this divide the throughput by 18 (twice for each 9 rates), leading
> to 200 - 300 kbits.
>
> When implementing proper TX status reporting, needed by minstrel rate
> control, I also found out that some 802.11 ACK where not received by the
> driver, but received by the card, leading to inconsistencies in the rate
> control code.
>
> Are there some registers that are responsible for ACK behavior?
>
> Regards,
> Benoit
>
>

ACK handling and retrying is one of the known weak points of the
zd1211(b) chipset - apparently enabling CR_SNIFFER causes the card to
ignore ACKs received. Also, the retry plan for unACKed outgoing
packets (retry count & rates) needs to be uploaded to the device on
firmware init, and can't be controlled per-packet.

Luis: Any chance of an open firmware release for the ZD1211, similarly
to what was done for AR9170/ZD1221? That would probably allow for
fixing these problems.

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

From forum: zd1211-devs

Re: monitor mode not capturing other BSS packets

2009-11-25T13:31:14Z

Benoit PAPILLAULT a écrit :
> TX rate is dropping a lot (like 20 MBits down to 200 kbits/s). Using
> another card in monitor mode, I still see packets sent at 54 Mbits rate
> however.
>
>
I found out what is wrong with the TX throughput. In fact, when a packet
is transmitted at 54 Mbits, the destination send back a 802.11 ACK which
is ignored!!! As such, the packet is transmitted at 54 Mbits once again,
then twice at 48 Mbits, then twice at 36 Mbits ... and so on down to 1
Mbits. Of course, this divide the throughput by 18 (twice for each 9
rates), leading to 200 - 300 kbits.

When implementing proper TX status reporting, needed by minstrel rate
control, I also found out that some 802.11 ACK where not received by the
driver, but received by the card, leading to inconsistencies in the rate
control code.

Are there some registers that are responsible for ACK behavior?

Regards,
Benoit

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

From forum: zd1211-devs

Re: monitor mode not capturing other BSS packets

2009-11-23T02:45:35Z

Benoit PAPILLAULT wrote:
> Very good point. I have two hardware here : one is zd1211 and the other
> is zd1211b. If I test with both, will it be ok?

IIRC, 2 of my ZD1211B devices behave differently.

Also, the reason that you lose performance is likely because the chip
will stop synchronizing its clock to the clock of the BSS that you are
connected to, and will instead attempt to be more flexible in terms of
receiving data from anywhere at any given time.

Daniel

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

From forum: zd1211-devs

Re: monitor mode not capturing other BSS packets

2009-11-23T02:26:40Z

Gábor Stefanik a écrit :

> 2009/11/22 Benoit PAPILLAULT <benoit.papillault@...>:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Gábor Stefanik a écrit :
>>
>>> Yes, that is probably the problem; please try this patch:
>>> http://patches.aircrack-ng.org/zd1211rw_inject_2.6.26.patch. It's just
>>> a hack, but it works. (Without the hack, only enabling CR_SNIFFER_ON
>>> will cause the card to return junk packets.)
>>>
>> Indeed. However :
>>
>> 1. I did not receive junk packet so far with only enabling CR_SNIFFER_ON.
>> 2. With both a STA interface and a monitor interface, performance drops
>> significantly. Any explanation for this.
>>
>
> What do you mean by "performance loss"? Is there packet loss? Is TX
> rate dropping?
>
>

TX rate is dropping a lot (like 20 MBits down to 200 kbits/s). Using
another card in monitor mode, I still see packets sent at 54 Mbits rate
however.

It seems that implementing monitor mode is not consistent over all
zd1211 devices and it has an impact on performance. Maybe we can :
1. Dig a big deeper into understanding register settings needed for
monitor mode.
2. Add a debugfs interface for enabling the use of CR_SNIFFER_ON in
monitor mode. IMHO, it could be enabled by default since users not using
monitor mode at all won't be affected and users doing monitor mode
expect it to work. In order to warn people, we can add a syslog messages
saying "Using CR_SNIFFER_ON register, your performance may degrade,
check /sys/kernel/debug/zd1211rw/use_cr_sniffer_on settings".

Comments?

Regards,
Benoit

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

From forum: zd1211-devs

Re: monitor mode not capturing other BSS packets

2009-11-23T02:19:43Z

Hin-Tak Leung a écrit :

> --- On Sun, 22/11/09, Daniel Drake <dsd@...> wrote:
>
>
>> Benoit PAPILLAULT wrote:
>>
>>> 1. I did not receive junk packet so far with only
>>>
>> enabling CR_SNIFFER_ON.
>>
>> The reason we flip-flopped once or twice in the past is
>> because
>> CR_SNIFFER_ON behaves wildly differently on different
>> revisions of the
>> ZD1211 hardware.
>>
>
> It is probably appropriate to document this as a comment next to CR_SNIFFER_ON in one of the headers.
>
>

Very good point. I have two hardware here : one is zd1211 and the other
is zd1211b. If I test with both, will it be ok?

Regards,
Benoit

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

From forum: zd1211-devs

Re: monitor mode not capturing other BSS packets

2009-11-22T18:26:59Z

--- On Mon, 23/11/09, Alejandro Grijalba <sud@...> wrote:

> Benoit PAPILLAULT escribió:
> > 1. I did not receive junk packet so far with only
> enabling CR_SNIFFER_ON.
> >
> If you apply the patch and there is a lot of wireless
> traffic going on
> you will start getting random frames too (sniffing with
> tcpdump on
> monitor interface or whatever). I have a couple of zd1211rw
> usb devices,
> and both do it.
> > 2. With both a STA interface and a monitor interface,
> performance drops
> > significantly. Any explanation for this.
> >
> Not sure, maybe because you are sniffing all frames in the
> channel, not
> only your BSS ones.
> > 3. Could you tell me a bit more about your junk packet
> filtering?
> >
> That patch is the mac80211 port of an older ieee80211 patch
> which was
> not done by me. The ~0x21 is a magic value that seems to
> work filtering
> junk frames. But i don't know what it means.
> > 4. I received lots of small RX packet of 4 or 5 bytes.
> What is causing this?
> >
> Maybe you are getting acks, or maybe it's part of the
> junk/random frames.
>
> Btw, how about enabling the CR_SNIFFER_ON patch as a module
> parameter so
> everyone is happy?

Expose it through /sysfs or /proc (so that it is dynamically selectable after module loading) may be even better, if it can be done...

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

From forum: zd1211-devs

Re: monitor mode not capturing other BSS packets

2009-11-22T17:44:50Z

Benoit PAPILLAULT escribió:
> 1. I did not receive junk packet so far with only enabling CR_SNIFFER_ON.
>
If you apply the patch and there is a lot of wireless traffic going on
you will start getting random frames too (sniffing with tcpdump on
monitor interface or whatever). I have a couple of zd1211rw usb devices,
and both do it.
> 2. With both a STA interface and a monitor interface, performance drops
> significantly. Any explanation for this.
>
Not sure, maybe because you are sniffing all frames in the channel, not
only your BSS ones.
> 3. Could you tell me a bit more about your junk packet filtering?
>
That patch is the mac80211 port of an older ieee80211 patch which was
not done by me. The ~0x21 is a magic value that seems to work filtering
junk frames. But i don't know what it means.
> 4. I received lots of small RX packet of 4 or 5 bytes. What is causing this?
>
Maybe you are getting acks, or maybe it's part of the junk/random frames.

Btw, how about enabling the CR_SNIFFER_ON patch as a module parameter so
everyone is happy?

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

From forum: zd1211-devs

Re: monitor mode not capturing other BSS packets

2009-11-22T15:43:30Z

--- On Sun, 22/11/09, Daniel Drake <dsd@...> wrote:

> Benoit PAPILLAULT wrote:
> > 1. I did not receive junk packet so far with only
> enabling CR_SNIFFER_ON.
>
> The reason we flip-flopped once or twice in the past is
> because
> CR_SNIFFER_ON behaves wildly differently on different
> revisions of the
> ZD1211 hardware.

It is probably appropriate to document this as a comment next to CR_SNIFFER_ON in one of the headers.

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

From forum: zd1211-devs

Re: monitor mode not capturing other BSS packets

2009-11-22T14:51:31Z

2009/11/22 Benoit PAPILLAULT <benoit.papillault@...>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Gábor Stefanik a écrit :
>> Yes, that is probably the problem; please try this patch:
>> http://patches.aircrack-ng.org/zd1211rw_inject_2.6.26.patch. It's just
>> a hack, but it works. (Without the hack, only enabling CR_SNIFFER_ON
>> will cause the card to return junk packets.)
>
> Indeed. However :
>
> 1. I did not receive junk packet so far with only enabling CR_SNIFFER_ON.
> 2. With both a STA interface and a monitor interface, performance drops
> significantly. Any explanation for this.

What do you mean by "performance loss"? Is there packet loss? Is TX
rate dropping?

> 3. Could you tell me a bit more about your junk packet filtering?

It was not written by me - CCing SuD, who wrote the patch.

> 4. I received lots of small RX packet of 4 or 5 bytes. What is causing this?
>
> Does your patch has been sent upstream already?
>
> Regards,
> Benoit
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAksJtdEACgkQOR6EySwP7oI0fwCg7wMKKTzlwGtEJax6oNBfuZi3
> R6sAoOsCUrp1bZzxrrh6j4mycGXru00u
> =xMHN
> -----END PGP SIGNATURE-----
>

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

From forum: zd1211-devs

Re: monitor mode not capturing other BSS packets

2009-11-22T14:28:23Z

Benoit PAPILLAULT wrote:
> 1. I did not receive junk packet so far with only enabling CR_SNIFFER_ON.

The reason we flip-flopped once or twice in the past is because
CR_SNIFFER_ON behaves wildly differently on different revisions of the
ZD1211 hardware.

Daniel

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

From forum: zd1211-devs

Re: monitor mode not capturing other BSS packets

2009-11-22T14:06:13Z

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

Gábor Stefanik a écrit :
> Yes, that is probably the problem; please try this patch:
> http://patches.aircrack-ng.org/zd1211rw_inject_2.6.26.patch. It's just
> a hack, but it works. (Without the hack, only enabling CR_SNIFFER_ON
> will cause the card to return junk packets.)

Indeed. However :

1. I did not receive junk packet so far with only enabling CR_SNIFFER_ON.
2. With both a STA interface and a monitor interface, performance drops
significantly. Any explanation for this.
3. Could you tell me a bit more about your junk packet filtering?
4. I received lots of small RX packet of 4 or 5 bytes. What is causing this?

Does your patch has been sent upstream already?

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

iEYEARECAAYFAksJtdEACgkQOR6EySwP7oI0fwCg7wMKKTzlwGtEJax6oNBfuZi3
R6sAoOsCUrp1bZzxrrh6j4mycGXru00u
=xMHN
-----END PGP SIGNATURE-----

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

From forum: zd1211-devs

Re: monitor mode not capturing other BSS packets

2009-11-20T17:35:29Z

On Sat, Nov 21, 2009 at 12:35 AM, Benoit PAPILLAULT
<benoit.papillault@...> wrote:

> Hello there,
>
> I'm trying to use monitor mode with zd1211b device and I'm currently
> using 2.6.32-rc7-wl kernel from wireless-testing git tree.
>
> What happens in monitor mode is that I only get DATA packets send to as
> broadcast or multicast addr. I'd like to use the card to capture traffic
> from other bss. I tried the iw flags otherbss when creating the monitor
> interface, but this change nothing.
>
> Is this a known problem? If so, where should i look for a fix?
>
> I remember playing with this device years ago and there was a CR_SNIFFER
> register that was set to 1. Apparently, this register is set to 0 now.
> Could it be the root of this issue?

Yes, that is probably the problem; please try this patch:
http://patches.aircrack-ng.org/zd1211rw_inject_2.6.26.patch. It's just
a hack, but it works. (Without the hack, only enabling CR_SNIFFER_ON
will cause the card to return junk packets.)

>
> Regards,
> Benoit
>
> ------------------------------------------------------------------------------
> 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
>

From forum: zd1211-devs

monitor mode not capturing other BSS packets

2009-11-20T15:35:33Z

Hello there,

I'm trying to use monitor mode with zd1211b device and I'm currently
using 2.6.32-rc7-wl kernel from wireless-testing git tree.

What happens in monitor mode is that I only get DATA packets send to as
broadcast or multicast addr. I'd like to use the card to capture traffic
from other bss. I tried the iw flags otherbss when creating the monitor
interface, but this change nothing.

Is this a known problem? If so, where should i look for a fix?

I remember playing with this device years ago and there was a CR_SNIFFER
register that was set to 1. Apparently, this register is set to 0 now.
Could it be the root of this issue?

Regards,
Benoit

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

From forum: zd1211-devs

[SHARE] vendor driver 3.0.0.56 AP configuration procedure

2009-11-14T05:10:30Z

After couple days of error & try, I finally figure out a procedure to achieve a WPA secured AP. I refine the steps for less variety

- Install CentOS 4.4 (kernel 2.6.9-42.EL). You need to install bridge-utils by "yum install bridge-utils".
- wget http://ftp.ntu.edu.tw/linux/kernel/people/mcgrof/zd1211/LinuxUSB_AR2524-3.0.0.56.tgz
- tar zvfx LinuxUSB_AR2524-3.0.0.56.tgz
- make
- cp -R apps/etc/ /
- insmod ar2524drv/zd1211b.ko zd1211_OperationMode=4
- < INSERT THE USB DONGLE >
- brctl addbr br0
- brctl setfd br0 0
- brctl addif br0 eth0
- brctl addif br0 ath0
- ifconfig br0 0.0.0.0
- ifconfig eth0 0.0.0.0
- ifconfig ath0 0.0.0.0
- echo "wpa_pairwise=CCMP" >> apps/hostapd-0.4.8/zydas.conf_psk
- echo "ssid=AP" >> apps/hostapd-0.4.8/zydas.conf_psk
- echo "wpa_passphrase=secrettext" >> apps/hostapd-0.4.8/zydas.conf_psk
- apps/hostapd-0.4.8/hostapd -d apps/hostapd-0.4.8/zydas.conf_psk

From forum: 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

From forum: 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

From forum: 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.

From forum: zd1211-devs

[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

From forum: 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

From forum: 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

From forum: 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

From forum: 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

From forum: 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.

From forum: zd1211-devs

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

From forum: 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

From forum: 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?
>
>
>
>

From forum: zd1211-devs

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

From forum: 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

From forum: 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

From forum: 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

From forum: 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

From forum: 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

From forum: 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

From forum: 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

From forum: 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

From forum: zd1211-devs