rtwn: refactor out datarate and short preamble setup

[adrian]

Summary

Refactor out the datarate setup and short preamble setup.
These will eventually be slightly different based on whether
firmware rate control is being performed or not.

Locally tested:

• RTL8192CU, STA mode

[fuz]

This also looks reasonable.

sys/dev/rtwn/rtl8192c/r92c_tx.c

266

Don't compare booleans with true/false.

[bz]

One question from me (which may or may not lead to a follow-up change) and one request for change from @fuz

sys/dev/rtwn/rtl8192c/r92c_tx.c

284

While this matches the original code moved...

So when I get to these things I am always confused as-to why we use the ic and not the vap version?
The ic is what the hardware can do but ignores what the peer can handle or the user has configured on the wlan interface, right? And then there's ni (though not in this case) if I remember correctly.
Can you elaborate on when to use which for me?

[adrian]

sys/dev/rtwn/rtl8192c/r92c_tx.c

284

While this matches the original code moved...

So when I get to these things I am always confused as-to why we use the ic and not the vap version?
The ic is what the hardware can do but ignores what the peer can handle or the user has configured on the wlan interface, right? And then there's ni (though not in this case) if I remember correctly.
Can you elaborate on when to use which for me?

Ok, for short-preamble in /specific/, there are two things to keep in mind:

• chipsets have it and other stuff globally configured, some chipsets have it configurable per-VAP / per-peer. eg, for ath and rtwn I think it can be done per-peer / per-frame for data rates. IIRC short preamble is a BSS option (as the AP should be tracking which peers can / can't support it.)

HOWEVER.

• when choosing short-preamble for management frames and control frames - such as RTS/CTS exchanges in particular - you may want to avoid using short-preamble for those in case other VAPs in a multi-VAP AP scenario that may have some REALLY legacy 11b devices can't decode them.

The history here is this is all in the ic from the pre-VAP times, and I'm not sure it was ever fully cleaned up.

Now, what we should do is create some more macros / inlines to clarify when to use what and some documentation around all of that as well.

FWIW - the same stuff applies for pure-g (OFDM only, no CCK), HT greenfield, etc. It was never done consistently and fully tested across multiple devices.