Re: [RFC 5/6] ath9k: enable DFS pulse detection

["Luis R. Rodriguez" <rodrigue@qca.qualcomm.com>]

On Tue, Oct 4, 2011 at 7:50 AM, Adrian Chadd <adrian@freebsd.org> wrote:
> Also whilst I'm at it, "SPECTRUM_MANAGEMENT" is a very broad flag to set.
>
> For example: you may not want to do DFS on the AR5416 NICs because (as
> documented in the open hal and earlier ath9k bits) there isn't support
> for radar pulses on the ext channel. So even if you had a successful
> DFS algorithm for this NIC, you'd have to somehow tell the DFS
> machinery that HT40+DFS channels aren't supported but HT20+DFS
> channels are.

Good point. I simply rather start out with the best possible DFS
support on Linux and go with the best hardware we have instead of
dealing with old hardware. Think about the support issues that can
come up with supporting the above. I rather simply not deal with it as
I also do not care about Turbo crap. Let legacy crap die.

> But then, the AR5416 supports per-packet TPC, so you could use it in
> STA mode perfectly fine and it'd support that part of spectrum
> management. Since you get per-frame RSSI of RX'ed frames, you can
> support the spectrum power histogram IE.

TPC is not implemented even in a lot of proprietary code bases,
although TPC is part of 802.11h its requirements are me by statically
reducing the maximum EIRP by 3 dB in frequency bands requiring TPC in
consideration for interference with satellites. In my latest
evaluation of TPC the only thing we want to do is simply enable the
option to explicitly state the max delta on power in consideration for
TPC in such a way that *if* TPC is implemented we can reduce the
reduction. But given that this is hardware specific and vendor
specific and not many people implement it right now I frankly don't
care too much about it. DFS is a bigger aspect.

  Luis