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 o
-
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 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
On 06-12-11 21:20 Michael Wu wrote:
> 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 tau
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
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:
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 is
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
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 devicesca
Hi John,
Please pull
git://git.kernel.org/pub/scm/linux/kernel/git/mwu/d80211-drivers.git week-48
for these patches:
Michael Wu (3):
zd1211rw-d80211: check IEEE80211_TXCTL_USE_CTS_PROTECT
zd1211rw-d80211: Use ieee80211_tx_status
zd1211rw-d80211: Use LED class
zd_chip.c |2
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
12 matches
Mail list logo
