rtwn: refactor out the r92c path protection decision / configuration

* refactor out the r92c path protection (RTS/CTS) decision
* handle firmware rate control being enabled - if DRVRATE isn't
set

rtwn: refactor out the r92c path protection decision / configuration

* refactor out the r92c path protection (RTS/CTS) decision
* handle firmware rate control being enabled - if DRVRATE isn't
set then the RTSRATE field is ignored and instead RRSR/INIRTS
registers are used (and the firmware/hardware will do RTS
rate adaptation / retry.)
* when making protection decisions with firmware rate control,
default to the channel mode rather than rate index.

This works on RTL8192CU both with firmware rate control and driver
rate control.

Locally tested:

* RTL8192CU, STA - firmware and net80211 rate control

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

show more ...

rtwn: refactor out datarate and short preamble setup

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

rtwn: refactor out datarate and short preamble setup

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

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

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: enable periodic TX reporting support on RTL8188EU NICs.

The RTL8188E firmware doesn't have the "full" offload firmware
rate control. Instead, the vendor driver has a bunch of logic
in the dri

rtwn: enable periodic TX reporting support on RTL8188EU NICs.

The RTL8188E firmware doesn't have the "full" offload firmware
rate control. Instead, the vendor driver has a bunch of logic
in the driver for rate probing and selection.

Part of this is the periodic TX report - which uploads a summary
of multi-rate retries and drops per MAC. Using it drastically
cuts down on the TX notifications - it's fired from a timer
(defaulting to ~ 1.6 seconds) and is a single receive frame in
the normal bulk RX path.

I've not ported / reimplemented the whole vendor driver rate adaption
code - instead, I'm just using the normal net80211 rate control APIs.
It seems to behave OK - I get 25-30mbit down and 20mbit up using TCP/
speedtest.

Locally tested:

* RTL8188EU, STA mode

Differential Revision: https://reviews.freebsd.org/D48088
Reviewed by: fuz, bz
Obtained from: https://github.com/lwfinger/rtl8188eu/blob/master/hal/Hal8188ERateAdaptive.c

show more ...

rtwn: remove SEQ_SEL, replace with a QOS bit

I've reviewed all of the linux vendor and upstream drivers.
This SEQ_SEL field isn't a mask and doesn't ever look like it
it was; instead this bit is set

rtwn: remove SEQ_SEL, replace with a QOS bit

I've reviewed all of the linux vendor and upstream drivers.
This SEQ_SEL field isn't a mask and doesn't ever look like it
it was; instead this bit is set to tag QoS data frames.

In fact, it effectively was set to 0 for STA frames and potentially 1
for broadcast/multicast frames as the STA macid of 0 and broadcast/
multicast macid of 1 maps to that. In AP modes it would be tagged
based on bit 0.

So, bring it in line with the vendor and linux drivers.

Locally tested:

* RTL8192CU, STA, hostap
* RTL8188EU, STA
* RTL8192EU, STA

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

show more ...

rtwn: disable a workaround introduced earlier for RTL8192CU TX performance

I'm unable to reproduce the original problem with my RTL8192CU USB
devices with the current codebase and I can't find any r

rtwn: disable a workaround introduced earlier for RTL8192CU TX performance

I'm unable to reproduce the original problem with my RTL8192CU USB
devices with the current codebase and I can't find any reference
to what this power register is doing - I see it defined in drivers,
but it's not described or used anywhere.

This reverts 7f740971658d71c1ee95ee68032b4696c1684845 -
rtwn_usb(4): fix Tx instability with RTL8192CU chipsets

In any case being able to do higher rate RTS/CTS is beneficial.

Local testing:

* rtl8192cu, STA mode, TX/RX testing

PR: 233949

Differential Revision: https://reviews.freebsd.org/D48026
Reviewed by: imp

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: 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: make sure to not write in upper bits of txdseq

ni_txseqs is kept as 16-bit counter, but we need to trim the upper four
bits as they may have special meanings for the firmware / hardware.
For i

rtwn: make sure to not write in upper bits of txdseq

ni_txseqs is kept as 16-bit counter, but we need to trim the upper four
bits as they may have special meanings for the firmware / hardware.
For instance, bit 15 enables hardware / firmware generation of sequence
numbers that overrides sequence numbers programmed by the driver.

Reviewed by: adrian
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D30814

show more ...

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

MFHead@r345275

MFhead@r344786

Merge ^/head r344549 through r344775.

rtwn_usb(4): fix Tx instability with RTL8192CU chipsets

- Fix data frames transmission via POWER_STATUS register setup -
it seems to be set by MACID_CONFIG firmware command, which was broken*
in r29

rtwn_usb(4): fix Tx instability with RTL8192CU chipsets

- Fix data frames transmission via POWER_STATUS register setup -
it seems to be set by MACID_CONFIG firmware command, which was broken*
in r290439 and later disabled in r307529.

We can re-enable it later if / when firmware rate adaptation will be
ready; however, this step will be required anyway - for firmware-less
builds.

- Force RTS / CTS protection frame rate to CCK1 (this rate works fine
without any additional setup; no better workaround is known yet).

The problem was not observed on the channel 1 or with CCK1 rate enforced
('ifconfig wlan0 ucastrate 1' for 11 b/g; not possible for 11n networks
due to ifconfig(8) bug).

* I'm not sure if it works before r290439 because - AFAIR - I never seen
firmware rate adaptation working for 10-STABLE urtwn(4)
(It needs EN_BCN bit set and RSSI updates at least).

Tested with RTL8188CUS in STA mode
(in regular mode and with disabled MRR - DARFRC*8 is set to 0)

PR: 233949
MFC after: 2 weeks

show more ...

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.

Merge ^/head r307383 through r307735.