ath9k: decouple RX error checking for DFS

Previous RX error checking was done exclusive-or for different error types and caused DFS pulse events to be dropped when other error flags (e.g. CRC) were set simultaneously.

This patch decouples PHY error processing from other types and ensures that all pulses detected by HW are accounted by the pattern detector.

---
 drivers/net/wireless/ath/ath9k/ar9003_mac.c |   12 ++++++------
 1 files changed, 6 insertions(+), 6 deletions(-)

index 09b8c9d..92e0042 100644
@@ -530,7 +530,11 @@ int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct ath_rx_status *rxs,
 		 */
 		if (rxsp->status11 & AR_CRCErr)
 			rxs->rs_status |= ATH9K_RXERR_CRC;
-		else if (rxsp->status11 & AR_PHYErr) {
+		else if (rxsp->status11 & AR_DecryptCRCErr)
+			rxs->rs_status |= ATH9K_RXERR_DECRYPT;
+		else if (rxsp->status11 & AR_MichaelErr)
+			rxs->rs_status |= ATH9K_RXERR_MIC;
+		if (rxsp->status11 & AR_PHYErr) {
 			phyerr = MS(rxsp->status11, AR_PHYErrCode);
 			/*
 			 * If we reach a point here where AR_PostDelimCRCErr is

@@ -552,11 +556,7 @@ int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct ath_rx_status *rxs,
 				rxs->rs_status |= ATH9K_RXERR_PHY;
 				rxs->rs_phyerr = phyerr;
 			}
-
-		} else if (rxsp->status11 & AR_DecryptCRCErr)
-			rxs->rs_status |= ATH9K_RXERR_DECRYPT;
-		else if (rxsp->status11 & AR_MichaelErr)
-			rxs->rs_status |= ATH9K_RXERR_MIC;
+		};
 	}
 
 	if (rxsp->status11 & AR_KeyMiss)

1.7.4.1

Hi,

Hm, so the AR9003 series NICs set PHY error _and_ decrypt/CRC error? On radar frames?

Interesting! Have you checked to see if the AR9280 does the same?

Adrian
________________________________________
From: Zefir Kurtisi [zefir.kurtisi at neratec.com]
Sent: Monday, 27 February 2012 3:52 AM
To: linville at tuxdriver.com
Cc: ath9k-devel at lists.ath9k.org; linux-wireless at vger.kernel.org; Rodriguez, Luis; Chadd, Adrian; Zefir Kurtisi
Subject: [PATCH] ath9k: decouple RX error checking for DFS

Previous RX error checking was done exclusive-or for different error types and caused DFS pulse events to be dropped when other error flags (e.g. CRC) were set simultaneously.

This patch decouples PHY error processing from other types and ensures that all pulses detected by HW are accounted by the pattern detector.

---
 drivers/net/wireless/ath/ath9k/ar9003_mac.c |   12 ++++++------
 1 files changed, 6 insertions(+), 6 deletions(-)

index 09b8c9d..92e0042 100644
@@ -530,7 +530,11 @@ int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct ath_rx_status *rxs,
                 */
                if (rxsp->status11 & AR_CRCErr)
                        rxs->rs_status |= ATH9K_RXERR_CRC;
-               else if (rxsp->status11 & AR_PHYErr) {
+               else if (rxsp->status11 & AR_DecryptCRCErr)
+                       rxs->rs_status |= ATH9K_RXERR_DECRYPT;
+               else if (rxsp->status11 & AR_MichaelErr)
+                       rxs->rs_status |= ATH9K_RXERR_MIC;
+               if (rxsp->status11 & AR_PHYErr) {
                        phyerr = MS(rxsp->status11, AR_PHYErrCode);
                        /*
                         * If we reach a point here where AR_PostDelimCRCErr is

@@ -552,11 +556,7 @@ int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct ath_rx_status *rxs,
                                rxs->rs_status |= ATH9K_RXERR_PHY;
                                rxs->rs_phyerr = phyerr;
                        }
-
-               } else if (rxsp->status11 & AR_DecryptCRCErr)
-                       rxs->rs_status |= ATH9K_RXERR_DECRYPT;
-               else if (rxsp->status11 & AR_MichaelErr)
-                       rxs->rs_status |= ATH9K_RXERR_MIC;
+               };
        }
 
        if (rxsp->status11 & AR_KeyMiss)

--
1.7.4.1

Hi Adrian,

finally found an AR9280 and repeated the tests simultaneously, i.e. identical radar pulses go to AR9390 and AR9280.

After several hours of continuous radar firing (pulse count in the 1M range), it looks like the AR9280 does not suffer from the reported problem, i.e. the PHY error is never reported in combination with other RX errors.

The AR9390 OTOH always follows the following scheme:
* it starts as expected with radar pulses being reported as PHY errors (RX descriptor word 11 set to status11=0x511)
* after a short time (about 80% probability within 5-20 mins) a single CRC error is reported (status11=0x005)
* the CRC error flag becomes sticky thereafter, all further radar pulses are reported with status11=0x515, i.e. PHY *and* CRC error

The posted patch fixes this issue for monitor mode. Not sure about implications for the soon to follow master mode, though.

Hi,

That's interesting. I have found the AR9280 to do the same. I hadn't gone digging into it though, I've been busy with other things but it was on my todo list. So thankyou for finding it. :-)

Specifically (and this is all under BSD):

* I'd start rx'ing radar errors;
* then they'd become crc errors;
* after some indeterminate amount of time, they'd drift back to being radar errors.

I'll reproduce it on the AR9280 and let you know how it goes.

Thanks for digging into it!

Adrian
________________________________________
From: Zefir Kurtisi [zefir.kurtisi at neratec.com]
Sent: Tuesday, 28 February 2012 3:57 AM
To: Chadd, Adrian
Cc: linville at tuxdriver.com; ath9k-devel at lists.ath9k.org; linux-wireless at vger.kernel.org; Rodriguez, Luis
Subject: Re: [PATCH] ath9k: decouple RX error checking for DFS

Hi Adrian,

finally found an AR9280 and repeated the tests simultaneously, i.e. identical radar pulses go to AR9390 and AR9280.

After several hours of continuous radar firing (pulse count in the 1M range), it looks like the AR9280 does not suffer from the reported problem, i.e. the PHY error is never reported in combination with other RX errors.

The AR9390 OTOH always follows the following scheme:
* it starts as expected with radar pulses being reported as PHY errors (RX descriptor word 11 set to status11=0x511)
* after a short time (about 80% probability within 5-20 mins) a single CRC error is reported (status11=0x005)
* the CRC error flag becomes sticky thereafter, all further radar pulses are reported with status11=0x515, i.e. PHY *and* CRC error

The posted patch fixes this issue for monitor mode. Not sure about implications for the soon to follow master mode, though.

Well, now I've looked at it. :-)

I see this exact behaviour on the AR5416. I'll test on the AR9130, AR9160 and AR9280 next week.

I'll chat with you next week about extending it to generate the chirp pulses and random interval PRI pulses. (And fixes to make it compile on FreeBSD rather than Linux; I have it running on FreeBSD, but it required some "fixes" to the source and Makefile.)

Thanks for doing the legwork on the USRP radar pulse generation stuff!

Adrian