Sometimes the AR5416 sends back radar PHY errors with both the PHY error

and the CRC error bits set.  The radar payload is correct.

When this happens, the stack doesn't see them PHY error frames and
isn't interpreted as a PHY error.  So, no radar detection and no radiotap
PHY error handling.

Now, this may introduce some weird issues if the MAC sends up some other
combination of CRC error + PHY error frames; this commit would break that
and mark them as PHY errors instead of CRC errors.

I may tinker with this a little more to pass radar/early radar/spectral
frames up as PHY errors if the CRC bit is set, to restore the previous
behaviour (where if CRC is set on a PHY error frame, it's marked as a CRC
error rather than PHY error.)

Tested on:	AR5416, over the air, to a USRP N200 which is generating a
		large number of a variety of radar pulses.
TODO:		Test on AR9130, AR9160, AR9280 (and maybe radar pulses on
		2GHz on AR9285/AR9287.)

PR:		kern/169362
This commit is contained in:
Adrian Chadd 2012-06-24 05:59:32 +00:00
parent c3fb2891f0
commit efb44bb8ca

View File

@ -228,15 +228,23 @@ ar5416ProcRxDesc(struct ath_hal *ah, struct ath_desc *ds,
* Consequently we filter them out here so we don't
* confuse and/or complicate drivers.
*/
if (ads->ds_rxstatus8 & AR_CRCErr)
rs->rs_status |= HAL_RXERR_CRC;
else if (ads->ds_rxstatus8 & AR_PHYErr) {
/*
* The AR5416 sometimes sets both AR_CRCErr and AR_PHYErr
* when reporting radar pulses. In this instance,
* clear HAL_RXERR_CRC and set HAL_RXERR_PHY.
*
* See PR kern/169362.
*/
if (ads->ds_rxstatus8 & AR_PHYErr) {
u_int phyerr;
rs->rs_status |= HAL_RXERR_PHY;
phyerr = MS(ads->ds_rxstatus8, AR_PHYErrCode);
rs->rs_phyerr = phyerr;
} else if (ads->ds_rxstatus8 & AR_DecryptCRCErr)
} else if (ads->ds_rxstatus8 & AR_CRCErr)
rs->rs_status |= HAL_RXERR_CRC;
else if (ads->ds_rxstatus8 & AR_DecryptCRCErr)
rs->rs_status |= HAL_RXERR_DECRYPT;
else if (ads->ds_rxstatus8 & AR_MichaelErr)
rs->rs_status |= HAL_RXERR_MIC;