Hi John,
Please pull
git://git.kernel.org/pub/scm/linux/kernel/git/mwu/d80211-drivers.git
for these patches:
adm8211-week05 branch:
Michael Wu (1):
adm8211: set MAC address properly
p54-week05 branch:
Michael Wu (3):
p54: set MAC address properly
p54usb: silence warnings on BE
Hi John,
Please pull
git://git.kernel.org/pub/scm/linux/kernel/git/mwu/d80211-drivers.git
for these patches:
adm8211-week51 branch:
adm8211: set phymode in RX
p54-week51 branch:
p54: fix device memory allocator
p54: fix TX of encrypted frames
p54: remove unnecessary use
-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Michael Buesch
Sent: Tuesday, December 12, 2006 1:35 AM
To: Daniel Drake
Cc: Michael Wu; John Linville; netdev@vger.kernel.org; Ulrich Kunitz
Subject: Re: d80211-drivers pull request (week-48)
On Tuesday 12 December 2006 02:07, Daniel
On Tuesday 12 December 2006 02:07, Daniel Drake wrote:
Michael Wu wrote:
zd1211rw-d80211: Use ieee80211_tx_status
I've thought some more about this and I'm not so sure that this is the
right approach.
Can't devicescape be taught that the ZD1211 handles retries in hardware
and
On Tuesday 12 December 2006 18:39, Ulrich Kunitz wrote:
Just two observations:
1) The retry-failed-interrupt message contains the destination
MAC address of the transmitted message.
Hm, that might be useful to check in master or adhoc mode to make sure the tx
queue isn't messed up.
2) We
On Monday 11 December 2006 20:07, Daniel Drake wrote:
Michael Wu wrote:
zd1211rw-d80211: Use ieee80211_tx_status
I've thought some more about this and I'm not so sure that this is the
right approach.
Can't devicescape be taught that the ZD1211 handles retries in hardware
and the
Michael Wu wrote:
I don't think this race is such a big deal. It will only happen when someone
is really trying to mess with the link, and would cause the rate control to
jump to the highest speed. However, if someone is really trying to mess with
the link this way, the stability of the link
On Monday 11 December 2006 22:51, Daniel Drake wrote:
It's ugly, in my mind not necessary, and it will kill performance. We
haven't had to make such compromises in a long time. We got a large TX
speed boost when the driver was modified to queue up multiple transmit
URBs (i.e. don't wait for
Michael Wu wrote:
zd1211rw-d80211: Use ieee80211_tx_status
I've thought some more about this and I'm not so sure that this is the
right approach.
Can't devicescape be taught that the ZD1211 handles retries in hardware
and the stack doesn't need to worry about it?
What does
Hi John,
Please pull
git://git.kernel.org/pub/scm/linux/kernel/git/mwu/d80211-drivers.git up
for these patches:
Michael Wu (4):
zd1211-d80211: Copy zd1211 driver to d80211 directory
zd1211-d80211: Hook up Kconfig and Makefiles
zd1211-d80211: Port zd1211 to Devicescape stack
10 matches
Mail list logo