Re: [ath9k-devel] [PATCH wireless-next] ath: Rename ath_print to ath_debug

2010-11-29 Thread Felix Fietkau
On 2010-11-30 2:39 AM, Joe Perches wrote: > On Mon, 2010-11-29 at 23:41 +0100, Felix Fietkau wrote: >> On 2010-11-29 7:07 AM, Peter Stuge wrote: >> > Luis R. Rodriguez wrote: >> >> On Sun, Nov 28, 2010 at 3:53 PM, Joe Perches wrote: >> >> > Make the function name match the function purpose. >> >>

Re: [ath9k-devel] [PATCH wireless-next] ath: Rename ath_print to ath_debug

2010-11-29 Thread Joe Perches
On Mon, 2010-11-29 at 23:41 +0100, Felix Fietkau wrote: > On 2010-11-29 7:07 AM, Peter Stuge wrote: > > Luis R. Rodriguez wrote: > >> On Sun, Nov 28, 2010 at 3:53 PM, Joe Perches wrote: > >> > Make the function name match the function purpose. > >> > ath_debug is a debug only facility. > >> > ath_

Re: [ath9k-devel] Script to crash ath9k with DMA errors.

2010-11-29 Thread Ben Greear
On 11/29/2010 04:44 PM, Luis R. Rodriguez wrote: > On Mon, Nov 29, 2010 at 04:28:51PM -0800, Ben Greear wrote: >> Here is a script that reliably crashes my ath9k box. >> A second box with completely different hardware (except >> for ath9k) experiences similar problems. >> BUG: unable to handle ker

Re: [ath9k-devel] Script to crash ath9k with DMA errors.

2010-11-29 Thread Luis R. Rodriguez
On Mon, Nov 29, 2010 at 04:28:51PM -0800, Ben Greear wrote: > Here is a script that reliably crashes my ath9k box. > A second box with completely different hardware (except > for ath9k) experiences similar problems. > > I am using today's wireless-testing kernel with a few > patches of my own. >

[ath9k-devel] Script to crash ath9k with DMA errors.

2010-11-29 Thread Ben Greear
Here is a script that reliably crashes my ath9k box. A second box with completely different hardware (except for ath9k) experiences similar problems. I am using today's wireless-testing kernel with a few patches of my own. You will also need the very latest hostap tree as it has the optimizations

Re: [ath9k-devel] [PATCH wireless-next] ath: Rename ath_print to ath_debug

2010-11-29 Thread Felix Fietkau
On 2010-11-29 7:07 AM, Peter Stuge wrote: > Luis R. Rodriguez wrote: >> On Sun, Nov 28, 2010 at 3:53 PM, Joe Perches wrote: >> > Make the function name match the function purpose. >> > ath_debug is a debug only facility. >> > ath_print seems too generic a name for a debug only use. >> >> Nack, I

Re: [ath9k-devel] [PATCH wireless-next] ath: Rename ath_print to ath_debug

2010-11-29 Thread Luis R. Rodriguez
On Mon, Nov 29, 2010 at 2:41 PM, Felix Fietkau wrote: > On 2010-11-29 7:07 AM, Peter Stuge wrote: >> Luis R. Rodriguez wrote: >>> On Sun, Nov 28, 2010 at 3:53 PM, Joe Perches wrote: >>> > Make the function name match the function purpose. >>> > ath_debug is a debug only facility. >>> > ath_print

[ath9k-devel] [PATCH] ath9k: Move debugfs under ieee80211/[phyname]/ath9k/

2010-11-29 Thread greearb
From: Ben Greear This fixes debugfs problems when a phy is renamed, and is able to remove a bit of code that is no longer needed. Signed-off-by: Ben Greear --- :100644 100644 0c3c74c... 3586c43... M drivers/net/wireless/ath/ath9k/debug.c :100644 100644 646ff7e... 1e5078b... M drivers/net/wire

Re: [ath9k-devel] Not able to connect to an access point with ar9271

2010-11-29 Thread Matthias Bernges
Hello, 2010/11/29 Mohammed Shafi : > On Sun, Nov 28, 2010 at 7:49 PM, Matthias Bernges > wrote: >> ,Hello, >> >> 2010/11/26 Mohammed Shafi : >>> On Fri, Nov 26, 2010 at 12:17 AM, Matthias Bernges >>> wrote: Hello, I've a TP-Link TL-WN422G using Atheros AR9271 chipset. I have

Re: [ath9k-devel] [AR9160] ath9k and Ubiquiti SR-71a - not getting anywhere near full TX power

2010-11-29 Thread Mohammed Shafi
On Mon, Nov 29, 2010 at 4:41 PM, Adrian Chadd wrote: > Oh, I know about where the chainmask is set to 1x1 for legacy mode. It > just means the effective TX power is in no way related to what the > specification sheet is. That's why I've enabled it for non-n mode in > my local FreeBSD HAL to evalua

Re: [ath9k-devel] ath9k_htc vs. powerpc (was Re: working usb wifi card, that is still possible to buy)

2010-11-29 Thread Sujith
Pavel Machek wrote: > We know the code currently works on PC; but this adds conversions that > are nop on PowerPC and do something on PC... so they should have no > effect on PowerPC and could break PC...? Well, I tested the patch on x86 and it seemed to work okay. But yeah, it needs to be tested

Re: [ath9k-devel] ath9k_htc vs. powerpc (was Re: working usb wifi card, that is still possible to buy)

2010-11-29 Thread Pavel Machek
Hi! > > ...so I indentified two endianness problems in eeprom, but even with > > both fixed, it still will not associate. Is there some way to dump USB > > packets, then compare them between PC and PowerPC versions? Should I > > expect them to match? > > Does this patch help ? Actually I wonder.

Re: [ath9k-devel] ath9k_htc vs. powerpc (was Re: working usb wifi card, that is still possible to buy)

2010-11-29 Thread Pavel Machek
Hi! > > ...so I indentified two endianness problems in eeprom, but even with > > both fixed, it still will not associate. Is there some way to dump USB > > packets, then compare them between PC and PowerPC versions? Should I > > expect them to match? > > Does this patch help ? No, it does not se

Re: [ath9k-devel] ath9k_htc vs. powerpc (was Re: working usb wifi card, that is still possible to buy)

2010-11-29 Thread Sujith
Pavel Machek wrote: > Hi! > > > > Sujith, I see you fought with endianness issues on ath9k_htc > > > driver. Was you able to test it on actual hardware? Should I try the > > > version just after your commit? > > > > No, I never had a chance to test the driver on a big-endian system. > > I assume

Re: [ath9k-devel] ath9k_htc vs. powerpc (was Re: working usb wifi card, that is still possible to buy)

2010-11-29 Thread Sujith
Pavel Machek wrote: > ...so I indentified two endianness problems in eeprom, but even with > both fixed, it still will not associate. Is there some way to dump USB > packets, then compare them between PC and PowerPC versions? Should I > expect them to match? Does this patch help ? diff --git a/dr

[ath9k-devel] How do I check if channel diversity is working?

2010-11-29 Thread Gianni Costanzi
Hi, I have a DNMA92 mini-pci wireless card (http://pcengines.ch/dnma92.htm) and I'm using it with two antennas on the 2.4Ghz band (802.11b/g). This is the output of lspci -vv 00:0e.0 Network controller: Atheros Communications Inc. AR922X Wireless Network Adapter (rev 01) Subsystem: Athero

[ath9k-devel] [patch] remove unneeded prototype on ath9k_htc

2010-11-29 Thread Pavel Machek
The prototype does not seem to have corresponding function. Signed-off-by: Pavel Machek diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h index cc8f3b9..ed5d199 100644 --- a/drivers/net/wireless/ath/ath9k/hw.h +++ b/drivers/net/wireless/ath/ath9k/hw.h @@ -9

Re: [ath9k-devel] [PATCH] fix endianity on ath9k_htc

2010-11-29 Thread Pavel Machek
Hi! > > It seems struct eep_header lacks proper #ifdef BIG_ENDIAN_BITFIELD > > markup. eep_4k_header has proper markup, but two fields were swapped. > > > > Signed-off-by: Pavel Machek > > > > diff --git a/drivers/net/wireless/ath/ath9k/eeprom.h > > b/drivers/net/wireless/ath/ath9k/eeprom.h >

Re: [ath9k-devel] [PATCH] fix endianity on ath9k_htc

2010-11-29 Thread Felix Fietkau
On 2010-11-29 10:58 AM, Pavel Machek wrote: > > It seems struct eep_header lacks proper #ifdef BIG_ENDIAN_BITFIELD > markup. eep_4k_header has proper markup, but two fields were swapped. > > Signed-off-by: Pavel Machek > > diff --git a/drivers/net/wireless/ath/ath9k/eeprom.h > b/drivers/net/wi

[ath9k-devel] [PATCH] ath9k_htc more cleanups

2010-11-29 Thread Pavel Machek
This fixes whitespace and fixes strings. Signed-off-by: Pavel Machek diff --git a/drivers/net/wireless/ath/ath9k/htc_hst.c b/drivers/net/wireless/ath/ath9k/htc_hst.c index c41ab8c..ac4aed7 100644 --- a/drivers/net/wireless/ath/ath9k/htc_hst.c +++ b/drivers/net/wireless/ath/ath9k/htc_hst.c @@ -1

Re: [ath9k-devel] [AR9160] ath9k and Ubiquiti SR-71a - not getting anywhere near full TX power

2010-11-29 Thread Adrian Chadd
Oh, I know about where the chainmask is set to 1x1 for legacy mode. It just means the effective TX power is in no way related to what the specification sheet is. That's why I've enabled it for non-n mode in my local FreeBSD HAL to evaluate its effects. I'll do some RF testing over the next few day

Re: [ath9k-devel] ath9k_htc vs. powerpc (was Re: working usb wifi card, that is still possible to buy)

2010-11-29 Thread Pavel Machek
Hi! > > > Sujith, I see you fought with endianness issues on ath9k_htc > > > driver. Was you able to test it on actual hardware? Should I try the > > > version just after your commit? > > > > No, I never had a chance to test the driver on a big-endian system. > > I assume you are referring to thi

[ath9k-devel] [PATCH] ath9k_htc cleanups

2010-11-29 Thread Pavel Machek
This fixes whitespace and reduces ammount of ifdefed lines. Signed-off-by: Pavel Machek diff --git a/drivers/net/wireless/ath/ath9k/eeprom.h b/drivers/net/wireless/ath/ath9k/eeprom.h index 3c99830..022589d 100644 --- a/drivers/net/wireless/ath/ath9k/eeprom.h +++ b/drivers/net/wireless/ath/ath9k

[ath9k-devel] [PATCH] fix endianity on ath9k_htc

2010-11-29 Thread Pavel Machek
It seems struct eep_header lacks proper #ifdef BIG_ENDIAN_BITFIELD markup. eep_4k_header has proper markup, but two fields were swapped. Signed-off-by: Pavel Machek diff --git a/drivers/net/wireless/ath/ath9k/eeprom.h b/drivers/net/wireless/ath/ath9k/eeprom.h index 3c99830..022589d 100644 ---

Re: [ath9k-devel] [AR9160] ath9k and Ubiquiti SR-71a - not getting anywhere near full TX power

2010-11-29 Thread Mohammed Shafi
On Mon, Nov 29, 2010 at 1:49 PM, Adrian Chadd wrote: > So it turns out that the SR-71A card TX power rates are quoted based > on the sum of all three chain TX'ing, rather than per-chain TX power. > > Given that legacy frames are transmitted through all chains anyway > (there's no special handling

Re: [ath9k-devel] [AR9160] ath9k and Ubiquiti SR-71a - not getting anywhere near full TX power

2010-11-29 Thread Adrian Chadd
So it turns out that the SR-71A card TX power rates are quoted based on the sum of all three chain TX'ing, rather than per-chain TX power. Given that legacy frames are transmitted through all chains anyway (there's no special handling in the TX path that limits the TX chainmask to 1 for non-11n fr