Copy stable/9 to releng/9.3 as part of the 9.3-RELEASE cycle.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

Copy head to stable/9 as part of 9.0-RELEASE release cycle.

Approved by: re (implicit)

Enable setting the short-GI bit when TX'ing HT rates but only if the
hardware supports it.

Since ni->ni_htcap in hostap mode is what the remote end has advertised,
not what has been negotiated/decided, we need to check ourselves what
the current channel width is and what the hardware supports before
enabling short-GI.

It's important that short-GI isn't enabled when it isn't negotiated
and when the hardware doesn't support it (ie, short-gi for 20mhz channels
on any chip < AR9287.)

I've quickly verified this on the AR9285 in 11n mode.

After discussing with Bernhard, the "right" way in net80211 to check
the channel width is ni->ni_chw, which is set to the negotiated channel
width. ni->ni_htflags is the capability, rather than the negotiated
value.

Teach both the TX path and the sample rate module about this.

Re-disable the setting of 2040/shortgi bits for now.

This seems to work fine for STA but not HT/20 AP mode.

Further discussion with net80211 people will need to take place
to ensure that the right flags are set based on the negotiated
capabilities of the remote peer, rather than whatever the local
parameters are.

Sending short-gi frames in 20mhz may work on some chips but
it certainly isn't supported on anything currently supported
by the HAL; and sending HT40 frames in HT20 mode just plain
won't work.

Flip back HT/40 and Short-GI (for 40mhz operation). These are now verified to work.

Clean up setting the short preamble bit in the rate - this way it
is very obvious (and cleanly so) that it occurs for non-11n rates.

The number of streams is not based on the interface stream count, but the
number of streams needed for that MCS rate.

Disable trying to do HT/40 and short-GI TX.

These flags are just plain wrong - they're the node flags from negotiation,
not the configured flags. I'll jump in later on and figure out exactly
what should be done to properly set these two flags when in both STA mode
(ie, what the AP says is possible and what's configured) and AP mode
(ie, where the AP has a configuration, but then negotiates what's possible
with each node, so per-node configuration can and will differ.)

This allows the 11n 2.4ghz/ht20 mode to associate (but perform poorly still)
and exchange MCS rates with atheros reference APs and a Cisco/Linksys
E3000 AP.

Don't set the RTS/CTS enable bit per-scenario if the global RTS/CTS
flags aren't set.

* Don't setup the scenario if the try count is 0
* Comment what else is going on during rate scenario setup

Implement setting the short preamble bit if it's needed for the current node.

Short preamble rates are only for legacy rates; MCS rate codes don't have a short
preamble code like this.

Just be double-sure short-gi isn't being enabled in 20mhz mode.

This should be TX stream, not RX stream.

The current code used the fields in ath_set11nratescenario() . Use them
correctly:

* pass in whether to allow the hardware to override the duration field
in the main data frame (durupdate_en) - PS_POLL frames in particular
don't have the duration bit overriden;
* there's no rts/cts duration here; that's done elsehwere

.. how'd this compile before I commit it and then not now?

Fixed.

The last parameter to ath_computedur_ht() is short-GI, not short-preamble.

Include some preliminary TX HT rate scenario setup code.

The AR5416 and later TX descriptors have new fields for supporting
11n bits (eg 20/40mhz mode, short/long GI) and enabling/disabling
RTS/CTS protection per rate.

These functions will be responsible for initialising the TX descriptors
for the AR5416 and later chips for both HT and legacy frames.

Beacon frames will remain using the non-11n TX descriptor setup for now;
Linux ath9k does much the same.

Note that these functions aren't yet used anywhere; a few more framework
changes are needed before all of the right rate information is available
for TX.