Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/

My initial rate control code was .. suboptimal.  I wanted to at least get MCS
rates sent, but it didn't do anywhere near enough to handle low signal level links
or remotely keep accurate statistics.

So, 8 years later, here's what I should've done back then.

* Firstly, I wasn't at all tracking packet sizes other than the two buckets
  (250 and 1600 bytes.)  So, extend it to include 4096, 8192, 16384, 32768 and
  65536.  I may go add 2048 at some point if I find it's useful.

  This is important for a few reasons.  First, when forming A-MPDU or AMSDU
  aggregates the frame sizes are larger, and thus the TX time calculation
  is woefully, increasingly wrong.  Secondly, the behaviour of 802.11 channels
  isn't some fixed thing, both due to channel conditions and radios themselves.
  Notably, there was some observations done a few years ago on 11n chipsets
  which noticed longer aggregates showed an increase in failed A-MPDU sub-frame
  reception as you got further along in the transmit time.  It could be due to
  a variety of things - transmitter linearity, channel conditions changing,
  frequency/phase drift, etc - but the observation was to potentially form
  shorter aggregates to improve BER.

* .. and then modify the ath TX path to report the length of the aggregate sent,
  so as the statistics kept would line up with the correct bucket.

* Then on the rate control look-up side - i was also only using the first frame
  length for an A-MPDU rate control lookup which isn't good enough here.
  So, add a new method that walks the TID software queue for that node to
  find out what the likely length of data available is.  It isn't ALL of the
  data in the queue because we'll only ever send enough data to fit inside the
  block-ack window, so limit how many bytes we return to roughly what ath_tx_form_aggr()
  would do.

* .. and cache that in the first ath_buf in the aggregate so it and the eventual
  AMPDU length can be returned to the rate control code.

* THEN, modify the rate control code to look at them both when deciding which bucket
  to attribute the sent frame on.  I'm erring on the side of caution and using the
  size bucket that the lookup is based on.

Ok, so now the rate lookups and statistics are "more correct".  However, MCS rates
are not the same as 11abg rates in that they're not a monotonically incrementing
set of faster rates and you can't assume that just because a given MCS rate fails,
the next higher one wouldn't work better or be a lower average tx time.

So, I had to do a bunch of surgery to the best rate and sample rate math.
This is the bit that's a WIP.

* First, simplify the statistics updates (update_stats()) to do a single pass on
  all rates.
* Next, make sure that each rate average tx time is updated based on /its/ failure/success.
  Eg if you sent a frame with { MCS15, MCS12, MCS8 } and MCS8 succeeded, MCS15 and MCS
  12 would have their average tx time updated for /their/ part of the transmission,
  not the whole transmission.
* Next, EWMA wasn't being fully calculated based on the /failures/ in each of the
  rate attempts.  So, if MCS15, MCS12 failed above but MCS8 didn't, then ensure
  that the statistics noted that /all/ subframes failed at those rates, rather than
  the eventual set of transmitted/sent frames.   This ensures the EWMA /and/ average
  TX time are updated correctly.
* When picking a sample rate and initial rate, probe rates aroud the current MCS
  but limit it to MCS0..7 /for all spatial streams/, rather than doing crazy things
  like hitting MCS7 and then probing MCS8 - MCS8 is basically MCS0 but two spatial
  streams.  It's a /lot/ slower than MCS7.  Also, the reverse is true - if we're at
  MCS8 then don't probe MCS7 as part of it, it's not likely to succeed.
* Fix bugs in pick_best_rate() where I was /immediately/ choosing the highest MCS
  rate if there weren't any frames yet transmitted.  I was defaulting to 25% EWMA and
  .. then each comparison would accept the higher rate.  Just skip those; sampling
  will fill in the details.

So, this seems to work a lot better.  It's not perfect; I'm still seeing a lot of
instability around higher MCS rates because there are bursts of loss/retransmissions
that aren't /too/ bad.  But i'll keep iterating over this and tidying up my hacks.

Ok, so why this still something I'm poking at? rather than porting minstrel_ht?

ath_rate_sample tries to minimise airtime, not maximise throughput.  I have
extended it with an EWMA based on sub-frame success/failures - high MCS rates
that have partially successful receptions still show super short average frame
times, but a /lot/ of retransmits have to happen for that to work.
So for MCS rates I also track this EWMA and ensure that the rates I'm choosing
don't have super crappy packet failures.  I don't mind not getting lower
peak throughput versus minstrel_ht; instead I want to see if I can make "minimise
airtime" work well.

Tested:

* AR9380, STA mode
* AR9344, STA mode
* AR9580, STA/AP mode

AR5416 and AR9280, but leave it disabled by default.

TL;DR: don't enable this code at all unless you go through the process
of getting the NIC re-certified.  This is purely to be used as a
reference and NOT a certified solution by any stretch of the imagination.

The background:

The AR5112 RF synth right up to the AR5133 RF synth (used on the AR5416,
derivative is used for the AR9130/AR9160) only implement down to 2.5MHz
channel spacing in 5GHz.  Ie, the RF synth is programmed in steps of 2.5MHz
(or 5, 10, 20MHz.) So they can't represent the quarter rate channels
in the 4.9GHz PSB (which end in xxx2MHz and xxx7MHz).  They support
fractional spacing in 2GHz (1MHz spacing) (or things wouldn't work,
right?)

So instead of doing this, the RF synth programming for the AR5112 and
later code will round to the nearest available frequency.

If all NICs were RF5112 or later, they'll inter-operate fine - they all
program the same. (And for reference, only the latest revision of the
RF5111 NICs do it, but the driver doesn't yet implement the programming.)

However:

* The AR5416 programming didn't at all implement the fractional synth
  work around as above;
* The AR9280 programming actually programmed the accurate centre frequency
  and thus wouldn't inter-operate with the legacy NICs.

So this patch:

* Implements the 4.9GHz PSB fractional synth workaround, exactly as the
  RF5112 and later code does;
* Adds a very dirty workaround from me to calculate the same channel
  centre "fudge" to the AR9280 code when operating on fractional frequencies
  in 5GHz.

HOWEVER however:

It is disabled by default.  Since the HAL didn't implement this feature,
it's highly unlikely that the AR5416 and AR928x has been tested in these
centre frequencies.  There's a lot of regulatory compliance testing required
before a NIC can have this enabled - checking for centre frequency,
for drift, for synth spurs, for distortion and spectral mask compliance.
There's likely a lot of other things that need testing so please don't
treat this as an exhaustive, authoritative list.  There's a perfectly good
process out there to get a NIC certified by your regulatory domain, please
go and engage someone to do that for you and pay the relevant fees.

If a company wishes to grab this work and certify existing 802.11n NICs
for work in these bands then please be my guest.  The AR9280 works fine
on the correct fractional synth channels (49x2 and 49x7Mhz) so you don't
need to get certification for that. But the 500KHz offset hack may have
the above issues (spur, distortion, accuracy, etc) so you will need to
get the NIC recertified.

Please note that it's also CARD dependent.  Just because the RF synth
will behave correctly doesn't at all mean that the card design will also
behave correctly.  So no, I won't enable this by default if someone
verifies a specific AR5416/AR9280 NIC works.  Please don't ask.

Tested:

I used the following NICs to do basic interoperability testing at
half and quarter rates.  However, I only did very minimal spectrum
analyser testing (mostly "am I about to blow things up" testing;
not "certification ready" testing):

* AR5212 + AR5112 synth
* AR5413 + AR5413 synth
* AR5416 + AR5113 synth
* AR9280

attached this way.

The AR5212 based NICs have a variety of RF frontends, so there's a linker set
which the AR5212 attach routine calls. The same framework is used for the
AR5416 and later but as there's a fixed RF frontend for each 11n NIC, it
is just directly attached.

However in the case of compiling a cut down HAL (eg _just_ AR9130 WMAC support),
the linker set ends up being empty and this causes the compile to fail.

So this is just a workaround for that - it means those users who wish an 11n
only HAL can compile the 11n chipsets and RF frontend they need, and just
"ath_ar5212" for the AR5212/AR5416 common code, and it'll just work.

Sponsored by:	Hobnob, Inc.

rather than global variables.

This specifically allows for debugging to be enabled per-NIC, rather
than globally.

Since the ath driver doesn't know about AH_DEBUG, and to keep the ABI
consistent regardless of whether AH_DEBUG is enabled or not, enable the
debug parameter always but only conditionally compile in the debug
methods if needed.

The ALQ support is currently still global pending some brainstorming.

Submitted by:	ssgriffonuser@gmail.com
Reviewed by:	adrian, bschmidt

I haven't seen a 5ghz AR9130 based board yet though!

Obtained from:	Atheros

The AR9130 is an AR9160/AR5416 family WMAC which is glued directly
to the AR913x SoC peripheral bus (APB) rather than via a PCI/PCIe
bridge.

The specifics:

* A new build option is required to use the AR9130 - AH_SUPPORT_AR9130.
  This is needed due to the different location the RTC registers live
  with this chip; hopefully this will be undone in the future.
  This does currently mean that enabling this option will break non-AR9130
  builds, so don't enable it unless you're specifically building an image
  for the AR913x SoC.

* Add the new probe, attach, EEPROM and PLL methods specific to Howl.

* Add a work-around to ah_eeprom_v14.c which disables some of the checks
  for endian-ness and magic in the EEPROM image if an eepromdata block
  is provided. This'll be fixed at a later stage by porting the ath9k
  probe code and making sure it doesn't break in other setups (which
  my previous attempt at this did.)

* Sprinkle Howl modifications throughput the interrupt path - it doesn't
  implement the SYNC interrupt registers, so ignore those.

* Sprinkle Howl chip powerup/down throughout the reset path; the RTC methods
  were

* Sprinkle some other Howl workarounds in the reset path.

* Hard-code an alternative setup for the AR_CFG register for Howl, that
  sets up things suitable for Big-Endian MIPS (which is the only platform
  this chip is glued to.)

This has been tested on the AR913x based TP-Link WR-1043nd mode, in
legacy, HT/20 and HT/40 modes.

Caveats:

* 2ghz has only been tested. I've not seen any 5ghz radios glued to this
  chipset so I can't test it.

* AR5416_INTERRUPT_MITIGATION is not supported on the AR9130. At least,
  it isn't implemented in ath9k. Please don't enable this.

* This hasn't been tested in MBSS mode or in RX/TX block-aggregation mode.