Ben Greear wrote:
Patrick McHardy has been working on patches for this feature
for me. I've hacked on it a small bit too, so he doesn't get all the
blame.
I'm attaching a patch that is mostly working:
Tested so far:
120 stations: Works OK with no encryption
10 stations: Works OK
This patch simplifies the code used to detect when the
self-linked DMA buffer is still in use by hardware, by
checking the hardware's rxdp register instead of looking
at the software buffer list.
Signed-off-by: Bob Copeland m...@bobcopeland.com
---
drivers/net/wireless/ath/ath5k/base.c | 24
Here are various fixes for ath5k. Patch 1 is the result of a script to
compare our initval tables against the ones in the open source HALs.
Patches 2 and 3 are self-explanatory. Patches 4 and 5 may help make a
use-after-free bug more rare (though it isn't fully solved - both need
some testing so
This patch corrects a few errors in the initvals tables to match those
in the HAL tables. Namely, remove a couple of repetitions, fix some
turbo mode errors, and correct a register for the CCK rate power table.
Changes-licensed-under: ISC
Signed-off-by: Bob Copeland m...@bobcopeland.com
---
For embedded platforms, beacon transmission can be starved when
flooded with data packets. Prioritize beacons by giving the beacon
queue the first shot when the isr completes.
Changes-licensed-under: 3-Clause-BSD
Signed-off-by: Bob Copeland m...@bobcopeland.com
---
Current code uses int types, but both modparams are boolean values.
Changes-licensed-under: 3-Clause-BSD
Signed-off-by: Bob Copeland m...@bobcopeland.com
---
drivers/net/wireless/ath/ath5k/base.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git
2009/4/15 Bob Copeland m...@bobcopeland.com:
For embedded platforms, beacon transmission can be starved when
flooded with data packets. Prioritize beacons by giving the beacon
queue the first shot when the isr completes.
Changes-licensed-under: 3-Clause-BSD
Signed-off-by: Bob Copeland
Hi Bob,
On Wed, Apr 15, 2009 at 12:57 PM, Bob Copeland m...@bobcopeland.com wrote:
This patch simplifies the code used to detect when the
self-linked DMA buffer is still in use by hardware, by
checking the hardware's rxdp register instead of looking
at the software buffer list.
Just an
John W. Linville wrote:
On Wed, Apr 15, 2009 at 11:58:39AM +0100, Alan Jenkins wrote:
[Corrected Luis address]
On 4/15/09, Alan Jenkins sourcejedi.l...@googlemail.com wrote:
Looking at the code, I think it does need fixing. There's even a
comment which says this finds them (or
On Wed, Apr 15, 2009 at 10:17 AM, Alan Jenkins
alan-jenk...@tuffmail.co.uk wrote:
Um, also the new ath module taints the kernel
Christian Lamparter posted a patch for that yesterday.
[ 4.176459] ath: Country alpha2 being used: 00
[ 4.176556] ath: Regpair detected: 0x60
[ 4.176679]
Bob Copeland wrote:
On Tue, Apr 14, 2009 at 01:48:55PM -0700, Ben Greear wrote:
===
[ INFO: possible circular locking dependency detected ]
2.6.29.1c3 #20
---
ip/3220 is trying to acquire
* Now that we have regulatory control enable the driver to set txpower on hw
* Also use txpower table offset so that we can match power range set by
user/driver with indices on power table.
Tested 2 different cards (a CM9 and an RF5112-based ubnt) and got the same
output using a remote
*Read Spur channel information from EEPROM and use default channels for RF5413
compatible chips that don't have this info on EEPROM.
Signed-off-by: Nick Kossifidis mickfl...@gmail.com
---
drivers/net/wireless/ath/ath5k/eeprom.c | 37 ++-
* Put remaining EEPROM information on ee struct and remove is_hb63 function.
Now we also have rfkill stuff available.
Signed-off-by: Nick Kossifidis mickfl...@gmail.com
---
drivers/net/wireless/ath/ath5k/eeprom.c | 24 +++-
drivers/net/wireless/ath/ath5k/eeprom.h |
After some debuging we were hitting the following bugs so far...
* Due to huge channel list hostapd couldn't get infos from the driver and
couldn't set
the channel. If we manualy set the channel after hostapd starts (by setting
channel to 0 -auto),
beacons are sent but they wont show up on
*Add spur filter support for RF5413 and later chips
Can someone test this ? I moved to Athens and i forgot to take the RF2425 with
me...
It should be ok as it comes from HAL sources.
Signed-off-by: Nick Kossifidis mickfl...@gmail.com
---
drivers/net/wireless/ath/ath5k/ath5k.h |5 +
On Thu, 2009-04-16 at 03:51 +0300, Nick Kossifidis wrote:
2009/4/16 Johannes Berg johan...@sipsolutions.net:
On Thu, 2009-04-16 at 03:24 +0300, Nick Kossifidis wrote:
*Read Spur channel information from EEPROM and use default channels for
RF5413 compatible chips that don't have this info
17 matches
Mail list logo
