On Tue, Oct 4, 2011 at 7:50 AM, Adrian Chadd <adrian@xxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
