-
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
