[PATCH 1/2] ath5k: Use high bitrates for ACK/CTS

[PATCH 1/2] ath5k: Use high bitrates for ACK/CTS

[Bruno Randolf]

There was a confusion in the usage of the bits AR5K_STA_ID1_ACKCTS_6MB and
AR5K_STA_ID1_BASE_RATE_11B. If they are set (1), we will get lower bitrates for
ACK and CTS. Therefore ath5k_hw_set_ack_bitrate_high(ah, false) actually
resulted in high bitrates, which i think is what we want anyways. Cleared the
confusion and added some documentation.

Signed-off-by: Bruno Randolf <br1@einfach.org>
---
 drivers/net/wireless/ath/ath5k/base.c |    3 +--
 drivers/net/wireless/ath/ath5k/pcu.c  |    4 ++--
 drivers/net/wireless/ath/ath5k/reg.h  |    4 ++--
 3 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index f7f57c1..3f59bc2 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -2558,8 +2558,7 @@ ath5k_init(struct ath5k_softc *sc)
 	for (i = 0; i < AR5K_KEYTABLE_SIZE; i++)
 		ath5k_hw_reset_key(ah, i);
 
-	/* Set ack to be sent at low bit-rates */
-	ath5k_hw_set_ack_bitrate_high(ah, false);
+	ath5k_hw_set_ack_bitrate_high(ah, true);
 	ret = 0;
 done:
 	mmiowb();
diff --git a/drivers/net/wireless/ath/ath5k/pcu.c b/drivers/net/wireless/ath/ath5k/pcu.c
index 710870e..174412f 100644
--- a/drivers/net/wireless/ath/ath5k/pcu.c
+++ b/drivers/net/wireless/ath/ath5k/pcu.c
@@ -154,9 +154,9 @@ void ath5k_hw_set_ack_bitrate_high(struct ath5k_hw *ah, bool high)
 	else {
 		u32 val = AR5K_STA_ID1_BASE_RATE_11B | AR5K_STA_ID1_ACKCTS_6MB;
 		if (high)
-			AR5K_REG_ENABLE_BITS(ah, AR5K_STA_ID1, val);
-		else
 			AR5K_REG_DISABLE_BITS(ah, AR5K_STA_ID1, val);
+		else
+			AR5K_REG_ENABLE_BITS(ah, AR5K_STA_ID1, val);
 	}
 }
 
diff --git a/drivers/net/wireless/ath/ath5k/reg.h b/drivers/net/wireless/ath/ath5k/reg.h
index 45d62e9..55b4ac6 100644
--- a/drivers/net/wireless/ath/ath5k/reg.h
+++ b/drivers/net/wireless/ath/ath5k/reg.h
@@ -1139,8 +1139,8 @@
 #define AR5K_STA_ID1_DEFAULT_ANTENNA	0x00200000	/* Use default antenna */
 #define AR5K_STA_ID1_DESC_ANTENNA	0x00400000	/* Update antenna from descriptor */
 #define AR5K_STA_ID1_RTS_DEF_ANTENNA	0x00800000	/* Use default antenna for RTS */
-#define AR5K_STA_ID1_ACKCTS_6MB		0x01000000	/* Use 6Mbit/s for ACK/CTS */
-#define AR5K_STA_ID1_BASE_RATE_11B	0x02000000	/* Use 11b base rate for ACK/CTS [5211+] */
+#define AR5K_STA_ID1_ACKCTS_6MB		0x01000000	/* Rate to use for ACK/CTS. 0: highest mandatory rate <= RX rate; 1: 1Mbps in B mode */
+#define AR5K_STA_ID1_BASE_RATE_11B	0x02000000	/* 802.11b base rate. 0: 1, 2, 5.5 and 11Mbps; 1: 1 and 2Mbps. [5211+] */
 #define AR5K_STA_ID1_SELFGEN_DEF_ANT	0x04000000	/* Use def. antenna for self generated frames */
 #define AR5K_STA_ID1_CRYPT_MIC_EN	0x08000000	/* Enable MIC */
 #define AR5K_STA_ID1_KEYSRCH_MODE	0x10000000	/* Look up key when key id != 0 */

[PATCH 2/2] ath5k: treat RXORN as non-fatal

[Bruno Randolf]

We get RXORN interrupts when all receive buffers are full. This is not
necessarily a fatal situation. It can also happen when the bus is busy or the
CPU is not fast enough to process all frames.

Older chipsets apparently need a reset to come out of this situration, but on
newer chips we can treat RXORN like RX, as going thru a full reset does more
harm than good, there.

The exact chip revisions which need a reset are unknown - this guess
AR5K_SREV_AR5212 ("venice") is copied from the HAL.

Inspired by openwrt 413-rxorn.patch:
"treat rxorn like rx, reset after rxorn seems to do more harm than good"

Signed-off-by: Bruno Randolf <br1@einfach.org>
---
 drivers/net/wireless/ath/ath5k/base.c |   15 ++++++++++++++-
 drivers/net/wireless/ath/ath5k/base.h |    1 +
 2 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 3f59bc2..9232742 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -2705,7 +2705,20 @@ ath5k_intr(int irq, void *dev_id)
 			 */
 			tasklet_schedule(&sc->restq);
 		} else if (unlikely(status & AR5K_INT_RXORN)) {
-			tasklet_schedule(&sc->restq);
+			/*
+			 * Receive buffers are full. Either the bus is busy or
+			 * the CPU is not fast enough to process all received
+			 * frames.
+			 * Older chipsets need a reset to come out of this
+			 * condition, but we treat it as RX for newer chips.
+			 * We don't know exactly which versions need a reset -
+			 * this guess is copied from the HAL.
+			 */
+			sc->stats.rxorn_intr++;
+			if (ah->ah_mac_srev < AR5K_SREV_AR5212)
+				tasklet_schedule(&sc->restq);
+			else
+				tasklet_schedule(&sc->rxtq);
 		} else {
 			if (status & AR5K_INT_SWBA) {
 				tasklet_hi_schedule(&sc->beacontq);
diff --git a/drivers/net/wireless/ath/ath5k/base.h b/drivers/net/wireless/ath/ath5k/base.h
index 53a5651..56221bc 100644
--- a/drivers/net/wireless/ath/ath5k/base.h
+++ b/drivers/net/wireless/ath/ath5k/base.h
@@ -135,6 +135,7 @@ struct ath5k_statistics {
 	unsigned int beacons;
 
 	unsigned int mib_intr;
+	unsigned int rxorn_intr;
 };
 
 #if CHAN_DEBUG

Re: [PATCH 1/2] ath5k: Use high bitrates for ACK/CTS

[Stanislaw Gruszka]

On Mon, 12 Apr 2010 16:38:47 +0900
Bruno Randolf <br1@einfach.org> wrote:

> There was a confusion in the usage of the bits AR5K_STA_ID1_ACKCTS_6MB and
> AR5K_STA_ID1_BASE_RATE_11B. If they are set (1), we will get lower bitrates for
> ACK and CTS. Therefore ath5k_hw_set_ack_bitrate_high(ah, false) actually
> resulted in high bitrates, which i think is what we want anyways. Cleared the
> confusion and added some documentation.

I thought ACK and other control frames have to be modulated at slow/robust
bitrates, but can't remember where I read that ...

Stanislaw

Re: [PATCH 1/2] ath5k: Use high bitrates for ACK/CTS

[Bruno Randolf]

On Friday 16 April 2010 22:59:07 Stanislaw Gruszka wrote:
> On Mon, 12 Apr 2010 16:38:47 +0900
> 
> Bruno Randolf <br1@einfach.org> wrote:
> > There was a confusion in the usage of the bits AR5K_STA_ID1_ACKCTS_6MB
> > and AR5K_STA_ID1_BASE_RATE_11B. If they are set (1), we will get lower
> > bitrates for ACK and CTS. Therefore ath5k_hw_set_ack_bitrate_high(ah,
> > false) actually resulted in high bitrates, which i think is what we want
> > anyways. Cleared the confusion and added some documentation.
> 
> I thought ACK and other control frames have to be modulated at slow/robust
> bitrates, but can't remember where I read that ...

this has been discussed on ath5k-devel before. i'm copying it here. please let 
me know if i missed something...

(https://lists.ath5k.org/pipermail/ath5k-devel/2010-March/003391.html)

control frames have to be sent at one of the lower bitrates - one of the 
"basic rates". in G mode these are 1, 2, 5.5, 11, 6, 12, 24Mbps. 

this is from the 802.11g spec:
"a STA responding to a received frame shall transmit its Control Response
(either CTS or ACK) frames at the highest rate in the BSSBasicRateSet that is 
less than or equal to the rate of the immediately previous frame in the frame 
exchange sequence (as defined in 9.7)"

basically we have to make a tradeoff here: using lower rates for ACK/CTS will 
improve reliability, but lower performance. for example i could get only 
10Mbps truput with ACK/CTS at the lowest bitrates and RTS/CTS enabled 
(iwconfig wlan0 rts 250) and i can get more than 20Mbps with higher bitrates. 
so i think it's worth to use high bitrates. actually also this should be 
tuneable for the user, too...

bruno

Re: [PATCH 1/2] ath5k: Use high bitrates for ACK/CTS

[Gábor Stefanik]

On Mon, Apr 19, 2010 at 2:24 AM, Bruno Randolf <br1@einfach.org> wrote:
> On Friday 16 April 2010 22:59:07 Stanislaw Gruszka wrote:
>> On Mon, 12 Apr 2010 16:38:47 +0900
>>
>> Bruno Randolf <br1@einfach.org> wrote:
>> > There was a confusion in the usage of the bits AR5K_STA_ID1_ACKCTS_6MB
>> > and AR5K_STA_ID1_BASE_RATE_11B. If they are set (1), we will get lower
>> > bitrates for ACK and CTS. Therefore ath5k_hw_set_ack_bitrate_high(ah,
>> > false) actually resulted in high bitrates, which i think is what we want
>> > anyways. Cleared the confusion and added some documentation.
>>
>> I thought ACK and other control frames have to be modulated at slow/robust
>> bitrates, but can't remember where I read that ...
>
> this has been discussed on ath5k-devel before. i'm copying it here. please let
> me know if i missed something...
>
> (https://lists.ath5k.org/pipermail/ath5k-devel/2010-March/003391.html)
>
> control frames have to be sent at one of the lower bitrates - one of the
> "basic rates". in G mode these are 1, 2, 5.5, 11, 6, 12, 24Mbps.

Aren't basic rates defined so as to exclude any OFDM rates? I.e. are
6M, 12M and 24M really basic rates?

>
> this is from the 802.11g spec:
> "a STA responding to a received frame shall transmit its Control Response
> (either CTS or ACK) frames at the highest rate in the BSSBasicRateSet that is
> less than or equal to the rate of the immediately previous frame in the frame
> exchange sequence (as defined in 9.7)"
>
> basically we have to make a tradeoff here: using lower rates for ACK/CTS will
> improve reliability, but lower performance. for example i could get only
> 10Mbps truput with ACK/CTS at the lowest bitrates and RTS/CTS enabled
> (iwconfig wlan0 rts 250) and i can get more than 20Mbps with higher bitrates.
> so i think it's worth to use high bitrates. actually also this should be
> tuneable for the user, too...
>
> bruno
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)