rtwn: add VHT20/VHT40/VHT80 bandwidth configuration for transmit.

Add a separate function and path for VHT 20/40/80MHz bandwidth
transmission.

Differential Revision: https://reviews.freebsd.org/D48

rtwn: add VHT20/VHT40/VHT80 bandwidth configuration for transmit.

Add a separate function and path for VHT 20/40/80MHz bandwidth
transmission.

Differential Revision: https://reviews.freebsd.org/D48102

show more ...

rtwn: don't set the RTS/CTS primary channel field for RTL8812AU/RTL8821AU

According to the rtl8812au reference driver, this seems to control
the bandwidth used by lower-bandwidth frames when transmi

rtwn: don't set the RTS/CTS primary channel field for RTL8812AU/RTL8821AU

According to the rtl8812au reference driver, this seems to control
the bandwidth used by lower-bandwidth frames when transmitted in
a higher bandwidth channel. For example, transmitting a 20MHz frame
on an 80MHz channel (eg in hostap mode) is doable, but you may want
to at least duplicate the RTS/CTS exchange across all four 20MHz
subchannels, AND perhaps duplicate the 20MHz frame.

I haven't fired this up with a spectrum analyser to see what the
result is.

The vendor driver doesn't bother with this and it doesn't change
performance. My guess is that for modes like AP mode we MAY wantto
be able to control the RTS/CTS bandwidth choices rather than letting
the firmare do it, but we're not there yet.

The rtl8812au code in hal/rtl8812a_xmit.c:SCMapping_8812() has
the gory details, but then the one place it's used just has it
commented out and 0 (ie "do not care") is always programmed in.

Differential Revision: https://reviews.freebsd.org/D48113
Obtained from: https://github.com/lwfinger/rtl8812au
Reviewed by: bz

show more ...

rtwn: calculate control rate for VHT rate frames

If the passed in rate is a VHT rate, use rtwn_ctl_vhtrate() to
find a suitable rate for RTS/CTS.

Differential Revision: https://reviews.freebsd.org

rtwn: calculate control rate for VHT rate frames

If the passed in rate is a VHT rate, use rtwn_ctl_vhtrate() to
find a suitable rate for RTS/CTS.

Differential Revision: https://reviews.freebsd.org/D48295
Reviewed by: bz, cy, emaste

show more ...

rtwn: add forcerate flag to TX descriptor setup

When doing firmware rate control there will be situations where
the rate being passed in needs to actually override the rate
control selection. So ad

rtwn: add forcerate flag to TX descriptor setup

When doing firmware rate control there will be situations where
the rate being passed in needs to actually override the rate
control selection. So add a flag to the descriptor setup path
to indicate that indeed this particular rate should be forced,
rather than rely on the firmware rate control.

This is currently a no-op as firmware rate control isn't working
in-tree, but it is working for me locally with other changes.
Without this, there's no way to force low rates for management,
DHCP traffic, and to allow fixed rate via "ifconfig wlanX ucastrate Y"
to function.

Locally tested:

* RTL8192CU, STA mode (firmware and driver/net80211 rate control)

Differential Revision: https://reviews.freebsd.org/D48100
Reviewed by: bz, gavin

show more ...

rtwn: expand the ridx numbers to include VHT; add accessor macros

* expand the ridx field all the way through 4x4 11n (MCS0..MCS31)
* and then expand it through VHT 4x4 (MCS0..9 for each stream)
* a

rtwn: expand the ridx numbers to include VHT; add accessor macros

* expand the ridx field all the way through 4x4 11n (MCS0..MCS31)
* and then expand it through VHT 4x4 (MCS0..9 for each stream)
* add accessor macros to check if the rate is HT, VHT
* use accessor macros to check if the rate is HT rather than
comparing it against OFDM54 or RIDX_HT_MCS(0); the values
aobve HT MCS will be VHT, and we don't want to trigger on those!
* add a couple of appropriate TODO VHT bits in the TX path

Locally tested:

* RTL8192CU, STA mode
* RTL8188EU, STA mode
* RTL8821AU, STA mode
* RTL8192EU, STA mode

Differential Revision: https://reviews.freebsd.org/D47896

show more ...

rtwn: use ieee80211_ht_check_tx_ht40() to transmit HT40 frames

Using ieee80211_ht_check_tx_ht40() means that not only the
bss and node channel are checked, but the ni_chw value is also
now correctly

rtwn: use ieee80211_ht_check_tx_ht40() to transmit HT40 frames

Using ieee80211_ht_check_tx_ht40() means that not only the
bss and node channel are checked, but the ni_chw value is also
now correctly checked.

Differential Revision: https://reviews.freebsd.org/D47862

show more ...

rtwn: fix rtl8812/rtl8821 vht definitions, add VHT calibration/rate control

* Add support for 80MHz channels during IQ calibration
* Correct the RAID flags for 1 and 2 stream VHT - the later ones

rtwn: fix rtl8812/rtl8821 vht definitions, add VHT calibration/rate control

* Add support for 80MHz channels during IQ calibration
* Correct the RAID flags for 1 and 2 stream VHT - the later ones
are for 2GHz VHT and then 3/4 stream VHT
* Add VHT to the RAID calculation for when we eventually transmit
VHT rates.

Obtained from: Linux rtw88 (https://github.com/lwfinger/rtw88)

Differential Revision: https://reviews.freebsd.org/D47774

show more ...

rtwn: use ieee80211_ht_get_node_ampdu_density(), fix programming MAX_AGG

* use ieee80211_ht_get_node_ampdu_density() now instead of the
vap->iv_ampdu_density, so the correct density is used in AP/

rtwn: use ieee80211_ht_get_node_ampdu_density(), fix programming MAX_AGG

* use ieee80211_ht_get_node_ampdu_density() now instead of the
vap->iv_ampdu_density, so the correct density is used in AP/IBSS/mesh
modes.

* MAX_AGG controls how many frames are to be sent in an A-MPDU.
It maps to ((MAX_AGG * 2) + 1) == npackets. 0x1f (31) means
64 packets. So, instead of hard-coding 0x1f, use the negotiated
block-ack window size.

Differential Revision: https://reviews.freebsd.org/D47766

show more ...

rtwn: use ieee80211_ht_check_tx_shortgi_20() and ieee80211_ht_check_tx_shortgi_40()

Use the new net80211 routines rather than rolling our own.

(The first version of this diff landed a previous vers

rtwn: use ieee80211_ht_check_tx_shortgi_20() and ieee80211_ht_check_tx_shortgi_40()

Use the new net80211 routines rather than rolling our own.

(The first version of this diff landed a previous version of what was
reviewed, so this brings it up to what was finally accepted in the
review.)

Differential Revision: https://reviews.freebsd.org/D47751

Reviewed by: bz

show more ...

rtwn: use ieee80211_ht_check_tx_shortgi_20() and ieee80211_ht_check_tx_shortgi_40()

Use the new net80211 routines rather than rolling our own.

Differential Revision: https://reviews.freebsd.org/D47

rtwn: use ieee80211_ht_check_tx_shortgi_20() and ieee80211_ht_check_tx_shortgi_40()

Use the new net80211 routines rather than rolling our own.

Differential Revision: https://reviews.freebsd.org/D47751

Reviewed by: bz

show more ...

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

rtwn: clean up empty lines in .c and .h files

rtwn(4): clear 'basic' rate bit before calculating RTS/CTS rate.

Rate tables have this bit set to indicate minimal set of basic rates;
however, it overlappes with MCS bit, so rate2ridx() will treat

rtwn(4): clear 'basic' rate bit before calculating RTS/CTS rate.

Rate tables have this bit set to indicate minimal set of basic rates;
however, it overlappes with MCS bit, so rate2ridx() will treat them as
an 11n rate.

Due to the current rates setup the issue can be reproduced only
in 5GHz band with 11n / protection enabled.

Tested with RTL8821AU, HOSTAP mode.

MFC after: 5 days

show more ...

MFH @ r323558.

MFhead@r323343

rtwn(4): some initial preparations for (basic) VHT support.

Rename RTWN_RIDX_MCS to RTWN_RIDX_HT_MCS before adding 802.11ac
MCS rate indexes (they have different offset).

No functional change inten

rtwn(4): some initial preparations for (basic) VHT support.

Rename RTWN_RIDX_MCS to RTWN_RIDX_HT_MCS before adding 802.11ac
MCS rate indexes (they have different offset).

No functional change intended.

show more ...

Merge ^/head r319251 through r319479.

rtwn: drop obsolete (since r319460) code.

Tested with RTL8188EU, STA mode.

MFhead@r313243

Merge ^/head r312309 through r312623.

rtwn: enable LDPC support where possible

Tested with RTL8821AU, STA mode.

Merge ^/head r307383 through r307735.

rtwn(4), urtwn(4): merge common code, add support for 11ac devices.

All devices:
- add support for rate adaptation via ieee80211_amrr(9);
- use short preamble for transmitted frames when needed;
- m

rtwn(4), urtwn(4): merge common code, add support for 11ac devices.

All devices:
- add support for rate adaptation via ieee80211_amrr(9);
- use short preamble for transmitted frames when needed;
- multi-bss support:
* for RTL8821AU: 2 VAPs at the same time;
* other: 1 any VAP + 1 sta VAP.
RTL8188CE:
- fix IQ calibration bug (reason of significant speed degradation);
- add h/w crypto acceleration support.
USB:
- A-MPDU Tx support;
- short GI support;
Other:
- add support for RTL8812AU / RTL8821AU chipsets
(a/b/g/n only; no ac yet);
- split merged code into subparts:
* bus glue (usb/*, pci/*, rtl*/usb/*, rtl*/pci/*)
* common (if_rtwn*)
* chip-specific (rtl*/*)
- various other bugfixes.

Due to code reorganization, module names / requirements were changed too:
urtwn urtwnfw -> rtwn rtwn_usb rtwnfw
rtwn rtwnfw -> rtwn rtwn_pci rtwnfw

Tested with RTL8188CE, RTL8188CUS, RTL8188EU and RTL8821AU.

Tested by: kevlo, garga,
Peter Garshtja <peter.garshtja@ambient-md.com>,
Kevin McAleavey <kevin.mcaleavey@knosproject.com>,
Ilias-Dimitrios Vrachnis <id@vrachnis.com>,
<otacilio.neto@bsd.com.br>
Relnotes: yes

show more ...