Jeff & Dave,
This patch adds z1211 (previously known as zd1211rw-mac80211),
a driver for Zydas ZD1211 hardware. This driver has proven very
robust -- Fedora 7 uses this driver and I don't think I have any open
bugzillas for it. Either the driver works well, or no one as using
it...given the common availability of the hardware, I have to presume
the former. :-)
This driver is mostly a port of zd1211rw to the mac80211
infrastructure. In fact, most zd1211rw patches have been mirrored
directly to this driver for some time. I considered merely updating
the existing driver with this code, but I think it is more prudent to
include this as a separate driver just to avoid confusion. There is
some symbol clash between the two drivers, so I add a Kconfig hack
to ensure that only one or the other is built-in or that this one is
built as a module.
The maintainers have identified some (IMHO minor) issues with the
mac80211 port of this driver. Some of them are summarized here:
http://linuxwireless.org/en/users/Drivers/zd1211rw/mac80211Issues
Still, I think we would be better-off having this driver upstream.
Thanks,
John
---
Patch is available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/0001-z1211-add-mac80211-based-driver-for-ZD1211-hardwa.patch
---
The following changes since commit 0d4cbb5e7f60b2f1a4d8b7f6ea4cc264262c7a01:
Linus Torvalds (1):
Linux 2.6.23-rc6
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git z1211
Daniel Drake (1):
z1211: add mac80211-based driver for ZD1211 hardware
MAINTAINERS | 10 +
drivers/net/wireless/Kconfig | 1 +
drivers/net/wireless/Makefile | 1 +
drivers/net/wireless/z1211/Kconfig | 18 +
drivers/net/wireless/z1211/Makefile | 10 +
drivers/net/wireless/z1211/zd_chip.c | 1619 ++++++++++++++++++++++++++++
drivers/net/wireless/z1211/zd_chip.h | 921 ++++++++++++++++
drivers/net/wireless/z1211/zd_def.h | 57 +
drivers/net/wireless/z1211/zd_ieee80211.c | 100 ++
drivers/net/wireless/z1211/zd_ieee80211.h | 75 ++
drivers/net/wireless/z1211/zd_mac.c | 949 ++++++++++++++++
drivers/net/wireless/z1211/zd_mac.h | 227 ++++
drivers/net/wireless/z1211/zd_rf.c | 178 +++
drivers/net/wireless/z1211/zd_rf.h | 108 ++
drivers/net/wireless/z1211/zd_rf_al2230.c | 439 ++++++++
drivers/net/wireless/z1211/zd_rf_al7230b.c | 492 +++++++++
drivers/net/wireless/z1211/zd_rf_rf2959.c | 279 +++++
drivers/net/wireless/z1211/zd_rf_uw2453.c | 534 +++++++++
drivers/net/wireless/z1211/zd_usb.c | 1528 ++++++++++++++++++++++++++
drivers/net/wireless/z1211/zd_usb.h | 263 +++++
drivers/net/wireless/z1211/zd_util.c | 82 ++
drivers/net/wireless/z1211/zd_util.h | 29 +
22 files changed, 7920 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/wireless/z1211/Kconfig
create mode 100644 drivers/net/wireless/z1211/Makefile
create mode 100644 drivers/net/wireless/z1211/zd_chip.c
create mode 100644 drivers/net/wireless/z1211/zd_chip.h
create mode 100644 drivers/net/wireless/z1211/zd_def.h
create mode 100644 drivers/net/wireless/z1211/zd_ieee80211.c
create mode 100644 drivers/net/wireless/z1211/zd_ieee80211.h
create mode 100644 drivers/net/wireless/z1211/zd_mac.c
create mode 100644 drivers/net/wireless/z1211/zd_mac.h
create mode 100644 drivers/net/wireless/z1211/zd_rf.c
create mode 100644 drivers/net/wireless/z1211/zd_rf.h
create mode 100644 drivers/net/wireless/z1211/zd_rf_al2230.c
create mode 100644 drivers/net/wireless/z1211/zd_rf_al7230b.c
create mode 100644 drivers/net/wireless/z1211/zd_rf_rf2959.c
create mode 100644 drivers/net/wireless/z1211/zd_rf_uw2453.c
create mode 100644 drivers/net/wireless/z1211/zd_usb.c
create mode 100644 drivers/net/wireless/z1211/zd_usb.h
create mode 100644 drivers/net/wireless/z1211/zd_util.c
create mode 100644 drivers/net/wireless/z1211/zd_util.h
--
John W. Linville
[email protected]
John W. Linville wrote:
> The maintainers have identified some (IMHO minor) issues with the
> mac80211 port of this driver. Some of them are summarized here:
>
> http://linuxwireless.org/en/users/Drivers/zd1211rw/mac80211Issues
>
> Still, I think we would be better-off having this driver upstream.
I apologise for being inactive over the last few weeks, I've been moving
back from the US to the UK and then moving back to university. However I
am now just-about-settled and will be active again soon.
I would like to this until 2.6.25 until I have had time to clear up some
final issues and do more testing myself of zd1211rw-mac80211. I also
think we need to discuss the rename...
(just to clarify to others: this is the first I heard of this merge
before John posted it).
John, thanks a lot for your efforts, I hope you don't mind waiting one
extra release cycle for me to sort a few things out.
Thanks,
Daniel
John W. Linville wrote:
> I know that you will argue that a rename is unnecessary if we
> simply port the existing driver to mac80211, which is certainly true.
> I just wonder if that is the least bumpy solution for users. At least
> with a new driver, if something doesn't work then the old driver is
> still there as a fallback. Plus you can avoid some confusion with
> old howtos and such on the web referring to an old driver instead
> of the new one, etc. Maybe that isn't a huge issue in this case,
> but I wouldn't underestimate the possible confusion.
Maybe I'll provide a one-off externally building driver for 2.6.25 or
something like that, just as a basis for comparison. I think biting the
bullet and simply attacking the issues that come up is the best way.
Old documentation will still be relevant for the mac80211 driver,
especially if we don't change the driver/config names -- offhand I can't
think of any obvious differences between the user interface to the 2
drivers.
>> (just to clarify to others: this is the first I heard of this merge
>> before John posted it).
>
> Yes, sorry...permission, forgiveness...forgive? :-)
Of course :)
> If you are determined not to have it in 2.6.24 then I will relent.
> I will also suggest that Larry start sending any softmac bugs to
> you... :-)
That's fine.
> If we will be having a port rather than a new driver, how soon after
> 2.6.24-rc1 closes can we queue the port for 2.6.25? I think it
> should be almost immediately, to ensure maximum test exposure and to
> "seal the deal". What do you think?
I think that's realistic, I'll do what I can.
Thanks,
Daniel
On Wed, Sep 19, 2007 at 11:12:50PM +0100, Daniel Drake wrote:
> John W. Linville wrote:
> BTW: I fairly regularly get email from F7 users complaining about
> connection intermittancy and other bugs that we don't seem to have for
> the softmac driver (maybe stack related issues, of which I've fixed a
> couple that affected me personally, I'm a little surprised that F7
> jumped so early).
Hmmm...please refer any of these to bugzilla.redhat.com if you don't mind.
John
--
John W. Linville
[email protected]
David Miller wrote:
> From: Daniel Drake <[email protected]>
> Date: Wed, 19 Sep 2007 23:08:16 +0100
>
>> John, thanks a lot for your efforts, I hope you don't mind waiting one
>> extra release cycle for me to sort a few things out.
>
> Having "a driver" is always better for users than having "no driver".
> Please I ask you not to block this merge even if you think it is too
> early.
I don't understand your point. We already have this driver in mainline
Linux.
zd1211rw-mac80211 does not currently add anything to the user experience
over the existing driver, other than automatic rate adaption which is
nice but hasn't proven itself to be of much importance given that the
existing driver has lots of happy users and has never done it.
Also, this merge has been proposed in a form other than what me and
Ulrich were envisioning (at least from earlier discussions). We want to
convert drivers/net/wireless/zd1211rw to mac80211 directly. This would
also avoid a rename and I think would save some hassle.
Sorry to be a pain, but I really would like some more time to catch up
and make some last changes. I haven't yet even looked at Johannes'
minimal filter flags implementation in the driver or Michael's fix.
Would you agree to let this wait until 2.6.25? You can hold me to that,
although Ulrich should also comment on if he thinks he'd be ready by then.
Thanks and apologies,
Daniel
On Thu, 2007-09-20 at 11:37 -0500, Larry Finger wrote:
> You're on. BTW, I will let you be the primary tester of "[PATCH] fix softmac lockdep reports" that
> Johannes posted earlier today. I see you were CC'd. I plan on testing it with bcm43xx, but I won't
> get to it for a couple of days.
The only thing it can possibly fix is our race against some other
functions that use the global workqueue and lock the RTNL from within
the work function while we have it locked while flushing. Conversely, it
can't really break anything either.
johannes
John W. Linville wrote:
> Jeff & Dave,
>
> This patch adds z1211 (previously known as zd1211rw-mac80211),
> a driver for Zydas ZD1211 hardware. This driver has proven very
> robust -- Fedora 7 uses this driver and I don't think I have any open
> bugzillas for it.
BTW: I fairly regularly get email from F7 users complaining about
connection intermittancy and other bugs that we don't seem to have for
the softmac driver (maybe stack related issues, of which I've fixed a
couple that affected me personally, I'm a little surprised that F7
jumped so early).
I've been suggesting that such users move to zd1211rw-softmac until both
Ulrich and myself are happy and we've made the jump upstream.
Daniel
Sorry for joining the discussion so late, but I have a day job
requires sometimes all of my time.
John W. Linville wrote:
> On Wed, Sep 19, 2007 at 11:08:16PM +0100, Daniel Drake wrote:
>
> > I would like to this until 2.6.25 until I have had time to clear up some
> > final issues and do more testing myself of zd1211rw-mac80211. I also
> > think we need to discuss the rename...
>
> Renames being what they are, I was hoping to avoid a "bikeshed"
> discussion about the choice of names. My main point was to get it
> into the tree with a unique and manageable name. I'm sure we could
> still rename it again before 2.6.24 ships or even later.
I would remark here that names are important. John you are
suggesting here the fourth rename of the mac80211 zd1211rw driver.
In my professional life I would clearly identify this as a
problem. I agree that zd1211rw-mac80211 is awkward, but this name
hasn't been introduced by Daniel or me. z1211 has never been used
to refer to the device. If a new name for zd1211rw-mac80211 has to
be found, we should use zd1211mac. This is a different name than
the for the softmac driver, which is zd1211rw. This should also
clarify my personal position, which is that different things
should be named differently. We cannot use zd1211, because this is
used by the out-of-tree vendor driver, which is still used by some
people.
> Well, obviously I would like to get it out now. The longer we are
> without a mac80211-based driver for zd1211 hardware then the longer
> we must maintain the softmac component (or at least take bug reports
> for it).
The problem from my perspective is, that mac80211 and our driver
is not there where it should be. Actually the softmac driver still
works better than the mac80211 driver. There are sometimes stops
with mac80211 for several seconds, which is pretty painful while
remotely editing text, which I do right now. Yes, I eat my own dog
food. The reason is that mac80211 has assumptions about the
features a device supports that we emulate quite badly, because
the device interface doesn't support the required semantics. (TX
confirmations is my major concern right now.) Multiple interfaces
don't work and I have been able to cause kernel crashes while
playing around with this. The driver doesn't support the setting
of certain configuration parameters while the device is down.
(Personally I think that should be handled by the stack, but it
doesn't right now.) We are receiving complains about kismet
compatibility once in a while.
You could ask, why we have not fixed those things. The problem is
that mac80211 right now is a moving target. I spent two weekends
simply to identify the patch, that caused a complete crash of the
kernel with the driver. At the same time the wireless-dev tree
reorg has been done, which destroyed the whole history. I wrote my
own git patch tool to be able to bisect. I found the patch, it had
around 2000 changed lines, it mixed code moves and some quick
fixes. Shortly afterwards a patch by Johannes fixed the problem. I
had not changed a line of the driver, but had spend around 50
hours on the problem. I apologize for the ranting. But I sometimes
feel, that Linux development is done under the assumption that
everybody has tons of midnight oil to burn.
Daniel and I are testing and reviewing every patch we are
forwarding to the wireless mailing list. It's not nice to spend
one to two hours again to adapt and test the pending patches,
because somebody has renamed the driver directory again.
> If you are determined not to have it in 2.6.24 then I will relent.
> I will also suggest that Larry start sending any softmac bugs to
> you... :-)
I think I have ranted enough. :-)
>
> If we will be having a port rather than a new driver, how soon after
> 2.6.24-rc1 closes can we queue the port for 2.6.25? I think it
> should be almost immediately, to ensure maximum test exposure and to
> "seal the deal". What do you think?
My minimum criteria for mainline inclusion are:
1) The driver doesn't crash anymore while playing around with
multiple interfaces. (I have to check this.)
2) A reasonable name has been chosen. My suggestion is zd1211mac.
A real high-quality driver will require Johannes' proposed
mac80211 driver interface changes to be merged and TX
confirmations handled in a way, that the semantics can really be
supported by the driver. (Michael Buesh's patch is taping over the
issue.)
Thanks,
Uli
--
Uli Kunitz
From: "John W. Linville" <[email protected]>
Date: Wed, 19 Sep 2007 14:10:05 -0400
> This patch adds z1211 (previously known as zd1211rw-mac80211),
> a driver for Zydas ZD1211 hardware. This driver has proven very
> robust -- Fedora 7 uses this driver and I don't think I have any open
> bugzillas for it. Either the driver works well, or no one as using
> it...given the common availability of the hardware, I have to presume
> the former. :-)
>
> This driver is mostly a port of zd1211rw to the mac80211
> infrastructure. In fact, most zd1211rw patches have been mirrored
> directly to this driver for some time. I considered merely updating
> the existing driver with this code, but I think it is more prudent to
> include this as a separate driver just to avoid confusion. There is
> some symbol clash between the two drivers, so I add a Kconfig hack
> to ensure that only one or the other is built-in or that this one is
> built as a module.
>
> The maintainers have identified some (IMHO minor) issues with the
> mac80211 port of this driver. Some of them are summarized here:
>
> http://linuxwireless.org/en/users/Drivers/zd1211rw/mac80211Issues
>
> Still, I think we would be better-off having this driver upstream.
Agreed, merged into net-2.6.24, thanks John.
On Saturday 22 September 2007, Ulrich Kunitz wrote:
> Michael Buesch wrote:
>
> > On Saturday 22 September 2007 11:48:00 Ulrich Kunitz wrote:
> > > A real high-quality driver will require Johannes' proposed
> > > mac80211 driver interface changes to be merged and TX
> > > confirmations handled in a way, that the semantics can really be
> > > supported by the driver. (Michael Buesh's patch is taping over the
> > > issue.)
> >
> > No it is not. It is fixing the issue. It fixes the following issues:
>
> > * You must ignore the Txstat-requested bit in the driver.
>
> If that is really the case the flag should be removed from
> mac80211. There is no way for somebody looking at the code to know
> this.
It is used internally in mac80211.
> > * You must report bad frames with the excessive_retries set.
>
> All bad frames or only those with actual excessive retries? Your patch
> set the excessive_retries flag for packets that couldn't be
> transmitted to the device because of an USB error. If the flag
> should be set for all kinds of errors it should be renamed.
Well, there is no better flag to set, currently.
Daniel Drake wrote:
> John W. Linville wrote:
>> If you are determined not to have it in 2.6.24 then I will relent.
>> I will also suggest that Larry start sending any softmac bugs to
>> you... :-)
>
> That's fine.
You're on. BTW, I will let you be the primary tester of "[PATCH] fix softmac lockdep reports" that
Johannes posted earlier today. I see you were CC'd. I plan on testing it with bcm43xx, but I won't
get to it for a couple of days.
Larry
From: David Miller <[email protected]>
Date: Wed, 19 Sep 2007 12:56:41 -0700 (PDT)
> I agreed with John to merge this in myself, but this patch
> applied to the old driver aparently, not the new z1211 one.
>
> Can you resend this patch against the new driver so I can
> add it to net-2.6.24?
Nevermind, John showed me that if I just edit the paths
in the patch it applied cleanly.
So I did that and pushed it to net-2.6.24, thanks!
On Wednesday 19 September 2007 20:59:03 David Miller wrote:
> From: "John W. Linville" <[email protected]>
> Date: Wed, 19 Sep 2007 14:10:05 -0400
>
> > This patch adds z1211 (previously known as zd1211rw-mac80211),
> > a driver for Zydas ZD1211 hardware. This driver has proven very
> > robust -- Fedora 7 uses this driver and I don't think I have any open
> > bugzillas for it. Either the driver works well, or no one as using
> > it...given the common availability of the hardware, I have to presume
> > the former. :-)
> >
> > This driver is mostly a port of zd1211rw to the mac80211
> > infrastructure. In fact, most zd1211rw patches have been mirrored
> > directly to this driver for some time. I considered merely updating
> > the existing driver with this code, but I think it is more prudent to
> > include this as a separate driver just to avoid confusion. There is
> > some symbol clash between the two drivers, so I add a Kconfig hack
> > to ensure that only one or the other is built-in or that this one is
> > built as a module.
> >
> > The maintainers have identified some (IMHO minor) issues with the
> > mac80211 port of this driver. Some of them are summarized here:
> >
> > http://linuxwireless.org/en/users/Drivers/zd1211rw/mac80211Issues
> >
> > Still, I think we would be better-off having this driver upstream.
>
> Agreed, merged into net-2.6.24, thanks John.
John, please also note that the following patch is not merged, yet.
http://bu3sch.de/patches/wireless-dev/20070915-1740/patches/006-zd-fix-tx-status.patch
Without it ratecontrol does not work. It does neither scale the rate
up nor down. This patch fixes both.
I think it got lost in a (really unrelated to the actual bug) discussion
about whether it's required or not to report status in mac80211 drivers.
(It turned out that it _is_ required).
--
Greetings Michael.
From: Daniel Drake <[email protected]>
Date: Wed, 19 Sep 2007 23:08:16 +0100
> John, thanks a lot for your efforts, I hope you don't mind waiting one
> extra release cycle for me to sort a few things out.
Having "a driver" is always better for users than having "no driver".
Please I ask you not to block this merge even if you think it is too
early.
Distribution vendors are going to merge this driver into their kernel
trees anyways. And as Linus stated at the recent kernel summit, when
this happens and upstream doesn't merge the driver too, the process
has failed.
We have had huge issues with shit piling up in the wireless tree and
it has to stop sooner rather than later, and I'm going to make sure
it stops now.
So please don't feel compelled to fix "all the issues" before a merge.
Drivers will always have issues, and if we merge now you will get more
useful feedback, sooner, and users will have something to use rather
than no driver at all.
Thanks.
Michael Buesch wrote:
> On Saturday 22 September 2007 11:48:00 Ulrich Kunitz wrote:
> > A real high-quality driver will require Johannes' proposed
> > mac80211 driver interface changes to be merged and TX
> > confirmations handled in a way, that the semantics can really be
> > supported by the driver. (Michael Buesh's patch is taping over the
> > issue.)
>
> No it is not. It is fixing the issue. It fixes the following issues:
> * You must ignore the Txstat-requested bit in the driver.
If that is really the case the flag should be removed from
mac80211. There is no way for somebody looking at the code to know
this.
> * You must report bad frames with the excessive_retries set.
All bad frames or only those with actual excessive retries? Your patch
set the excessive_retries flag for packets that couldn't be
transmitted to the device because of an USB error. If the flag
should be set for all kinds of errors it should be renamed.
> The issue you are (most likely) talking about is that we can not
> reliably tell whether a frame was good in the driver. That is a different
> issue completely seperate from the two points above, which my patch fixes.
This has been the reason, why I stated "taped over".
The issues are:
* The driver cannot reliably tell, whether the transmission of
particular packet to the same address failed but is forced by
mac80211 to pretend this.
* Currently the device reports ACKs over the USB interface, which
increases the interrupt load. The ACKs can also not reliably
paired with the transmitted packet. Sending only one packet in parallel
per destination address to the device and wait for a timeout
would slow things down.
I would like to see that the driver would only be required to
report the status for single packets in critical phases like
associations. In other situations the driver should only be
requested to support statistics.
> With my patch rate-controlling correctly works. Without it does not.
> If you find a way to fix the reliable-detection-of-good-TX issue, that's
> another good fix. But I think it's not release critical, because the
> device works with the current "guessing-around" code. But without the two
> points above fixed, it does not correctly work at all (unless you manually
> tune to the best rate each time you move the machine).
Your patch clearly fixed the problem of the missing excessive
retries flag. But it should be accomponied by patches of
mac80211. One could fix the request-tx-status flag situation.
Another could rename the excessive_retries flag to tx_error.
--
Uli Kunitz
On Wed, Sep 19, 2007 at 11:08:16PM +0100, Daniel Drake wrote:
> I would like to this until 2.6.25 until I have had time to clear up some
> final issues and do more testing myself of zd1211rw-mac80211. I also
> think we need to discuss the rename...
Renames being what they are, I was hoping to avoid a "bikeshed"
discussion about the choice of names. My main point was to get it
into the tree with a unique and manageable name. I'm sure we could
still rename it again before 2.6.24 ships or even later.
I know that you will argue that a rename is unnecessary if we
simply port the existing driver to mac80211, which is certainly true.
I just wonder if that is the least bumpy solution for users. At least
with a new driver, if something doesn't work then the old driver is
still there as a fallback. Plus you can avoid some confusion with
old howtos and such on the web referring to an old driver instead
of the new one, etc. Maybe that isn't a huge issue in this case,
but I wouldn't underestimate the possible confusion.
> (just to clarify to others: this is the first I heard of this merge
> before John posted it).
Yes, sorry...permission, forgiveness...forgive? :-)
> John, thanks a lot for your efforts, I hope you don't mind waiting one
> extra release cycle for me to sort a few things out.
Well, obviously I would like to get it out now. The longer we are
without a mac80211-based driver for zd1211 hardware then the longer
we must maintain the softmac component (or at least take bug reports
for it).
If you are determined not to have it in 2.6.24 then I will relent.
I will also suggest that Larry start sending any softmac bugs to
you... :-)
If we will be having a port rather than a new driver, how soon after
2.6.24-rc1 closes can we queue the port for 2.6.25? I think it
should be almost immediately, to ensure maximum test exposure and to
"seal the deal". What do you think?
Thanks,
John
--
John W. Linville
[email protected]
From: Daniel Drake <[email protected]>
Date: Wed, 19 Sep 2007 23:27:09 +0100
> zd1211rw-mac80211 does not currently add anything to the user experience
> over the existing driver, other than automatic rate adaption which is
> nice but hasn't proven itself to be of much importance given that the
> existing driver has lots of happy users and has never done it.
Ok.
> Also, this merge has been proposed in a form other than what me and
> Ulrich were envisioning (at least from earlier discussions). We want to
> convert drivers/net/wireless/zd1211rw to mac80211 directly. This would
> also avoid a rename and I think would save some hassle.
>
> Sorry to be a pain, but I really would like some more time to catch up
> and make some last changes. I haven't yet even looked at Johannes'
> minimal filter flags implementation in the driver or Michael's fix.
>
> Would you agree to let this wait until 2.6.25? You can hold me to that,
> although Ulrich should also comment on if he thinks he'd be ready by then.
Fair enough, I'll remove the Z1211 driver during my next rebase.
On Saturday 22 September 2007 11:48:00 Ulrich Kunitz wrote:
> A real high-quality driver will require Johannes' proposed
> mac80211 driver interface changes to be merged and TX
> confirmations handled in a way, that the semantics can really be
> supported by the driver. (Michael Buesh's patch is taping over the
> issue.)
No it is not. It is fixing the issue. It fixes the following issues:
* You must ignore the Txstat-requested bit in the driver.
* You must report bad frames with the excessive_retries set.
The issue you are (most likely) talking about is that we can not
reliably tell whether a frame was good in the driver. That is a different
issue completely seperate from the two points above, which my patch fixes.
With my patch rate-controlling correctly works. Without it does not.
If you find a way to fix the reliable-detection-of-good-TX issue, that's
another good fix. But I think it's not release critical, because the
device works with the current "guessing-around" code. But without the two
points above fixed, it does not correctly work at all (unless you manually
tune to the best rate each time you move the machine).
--
Greetings Michael.
From: Michael Buesch <[email protected]>
Date: Wed, 19 Sep 2007 21:23:16 +0200
> John, please also note that the following patch is not merged, yet.
> http://bu3sch.de/patches/wireless-dev/20070915-1740/patches/006-zd-fix-tx-status.patch
> Without it ratecontrol does not work. It does neither scale the rate
> up nor down. This patch fixes both.
I agreed with John to merge this in myself, but this patch
applied to the old driver aparently, not the new z1211 one.
Can you resend this patch against the new driver so I can
add it to net-2.6.24?
Thanks!