Hi all,
I've been playing around with an AR5414, MadWifi and ath5k (through compat-wireless-2011-10-11) - seriously impressed with all the works that's been done! I noticed that DFS is still on the to-do list, and found that it's not exactly 'connected' in the source. I was wondering if someone could confirm whether my understanding is correct regarding the following (and fill in the blanks): Detection of a radar (periodic radar-like pulsed) signal is done by the PHY iff the LSB of the AR5K_PHY_RADAR register is set (i.e. to AR5K_PHY_RADAR_ENABLE). I added AR5K_PHY_RADAR to the register list dumped by <debugfs>/registers, but found that AR5K_PHY_RADAR_ENABLE was disabled according to the above (always 0x5d50e188, which matches the AR5212 AR5K_PHY_RADAR default in initvals.c, i.e. LSB is 0). Therefore I OR'd the enabled-bit into the initial value of that register in initvals.c to force it to be always on, and a register readback via debugfs confirms it's in the hardware. Once the PHY has detected a radar-like signal, the only way it is reported back to the driver is by the hardware setting the AR5K_PHY_ERR_FIL_RADAR bit in the AR5K_PHY_ERR_FIL register, which currently is only read in ath5k_hw_get_rx_filter, and ORs AR5K_RX_FILTER_RADARERR into the filter value returned from that function. I've added a counter that is incremented each time AR5K_PHY_ERR_FIL_RADAR is found in that function. I assumed that if the AR5K_PHY_RADAR_ENABLE bit was set, AR5K_PHY_ERR_FIL_RADAR would be set in the presence of radar signal, which would then cause the AR5K_RX_FILTER_RADARERR to be returned and used later to enable the radar filter (e.g. in ath5k_configure_filter). Is this correct? Or does the radar filter ALSO need to be enabled beforehand, not just the AR5K_PHY_RADAR_ENABLE bit? (I tested this too, read on.) I've done tests in various modes and on different channels, particularly Master with hostapd & manual channel selection. I have found that forcing the AR5K_PHY_RADAR_ENABLE bit has no effect, and if I force the radar filter on (rfilt |= AR5K_RX_FILTER_RADARERR;) in ath5k_configure_filter, then the radar counter increments every call (i.e. R5K_PHY_ERR_FIL_RADAR bit in the AR5K_PHY_ERR_FIL register is ALWAYS set, this doesn't sound right on a standard WiFi channel). I'm sure there's something missing here, but basically: Does the PHY actually do the radar detection on its own once the AR5K_PHY_RADAR_ENABLE bit is set, or does it have to be in a particular mode/do something special? >From my understanding DFS is supposed to be for APs that sense the spectrum during quiet periods between beacons. I'm not sure how this fits in with the ath5k hardware/driver. Should radar detection work for Managed/Ad-Hoc/Monitor also? How/why does AR5K_RX_FILTER_RADARERR affect the AR5K_PHY_ERR_FIL register (i.e. why is AR5K_PHY_ERR_FIL_RADAR always set when that filter is manually enabled on a standard 5GHz channel, e.g. 40)? Does that register need to be reset after a read (i.e. it's a spurious error that needs to be cleared when the interface is initially brought up)? Ideally if DFS was implemented fully in the driver, where would radar PHY errors be handled? Would they be caught by periodically checking the AR5K_PHY_ERR_FIL register or by some other means? Basically, I'd just like to see how good the radar detection of the PHY is, and to do that I'd like to find out from the driver when it actually does pick up a signal! I know the initvals.c AR5K_PHY_RADAR value encodes the pulse strength/height/RSSI, which I image is set to sensible defaults. Do I need to modify these also to make it more sensitive? Thank you very much for your insight, Balint
_______________________________________________ ath5k-devel mailing list [email protected] https://lists.ath5k.org/mailman/listinfo/ath5k-devel
