rtwn: announce VHT support for RTL8812AU/RTL8821AU.

Although the transmit path doesn't yet support VHT rates (because
the rate control and rate representation in net80211 doesn't yet
know about VHT

rtwn: announce VHT support for RTL8812AU/RTL8821AU.

Although the transmit path doesn't yet support VHT rates (because
the rate control and rate representation in net80211 doesn't yet
know about VHT rates) the NIC will receive VHT frames but only
transmit HT frames.

Locally tested:

* RTL8812AU, STA mode

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

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: add support for register IO debugging

Add support to read/write the MAC/PHY registers.

Hide it behind RTWN_DEBUG.

This doesn't cover the RF registers as they require a different
IO path, but

rtwn: add support for register IO debugging

Add support to read/write the MAC/PHY registers.

Hide it behind RTWN_DEBUG.

This doesn't cover the RF registers as they require a different
IO path, but I haven't yet debugged the RF paths.

Locally tested:

* RTL8192CU, STA
* RTL8188EU, STA
* RTL8812AU / RTL8821AU, STA

Differential Revision: https://reviews.freebsd.org/D48084
Reviewed by: bz

show more ...

rtwn: create a new HAL routine for enabling STA mode beacon processing

For some NICs (notably the rtl8192cu that I'm working on) the
firmware rate adaptation requires beacon processing to be enabled

rtwn: create a new HAL routine for enabling STA mode beacon processing

For some NICs (notably the rtl8192cu that I'm working on) the
firmware rate adaptation requires beacon processing to be enabled.

Instead of making assumptions in the if_rtwn beacon routines (and
honestly all of that should be in the HAL too), create a HAL method
for enabling/disabling beacon processing specifically in STA mode.

Since this isn't necessarily required for all NICs (notably the RTL8188E
NICs, where some will do firmware rate control and some will require
driver rate control), only enable it for the RTL8192CU and RT8192EU.

The RTL8188E and RTL8812/RTL8821 just have no-op routines for now.

Locally tested:

* RTL8192CU, STA mode

Differential Revision: https://reviews.freebsd.org/D48066
Reviewed by: bz

show more ...

rtwn: add APIs for setting transmit power

The RTL8188/RTL8192/RTL8821/RTL8812 NICs all seem happy to have
their transmit power changed at runtime - and it does seem to do
what's expected - the trans

rtwn: add APIs for setting transmit power

The RTL8188/RTL8192/RTL8821/RTL8812 NICs all seem happy to have
their transmit power changed at runtime - and it does seem to do
what's expected - the transmit power level does change.

So, add the API call here, even though it's all currently no-ops.
A follow-up commit will land changes for the chipsets to both
limit transmit power to the configured / regulatory limit AND
allow reconfiguration at runtime.

Differential Revision: https://reviews.freebsd.org/D47979
Reviewed by: bz, imp

show more ...

rtwn: add placeholder for the per-MACID rate report

Some chipsets (such as the RTL8188E) have firmware which supports
a second kind of TX report - instead of a per-packet TX report,
it can generate

rtwn: add placeholder for the per-MACID rate report

Some chipsets (such as the RTL8188E) have firmware which supports
a second kind of TX report - instead of a per-packet TX report,
it can generate a per-MACID summary of packet success/failure counters.

This would be helpful for those chips to cut back on the USB traffic
to get rate control feedback for the driver based rate control we're
currently using.

This is a no-op; it just gets the pieces in place for future work.

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

show more ...

rtwn: don't do 64 bit TSF extension by default

The TSF64 extension involves at least 3 reads from TSF registers
(R92C_TSFTR(0), R92C_TSFTR(1), R92C_TSFTR(2)) which are 4 byte
control transfers. The

rtwn: don't do 64 bit TSF extension by default

The TSF64 extension involves at least 3 reads from TSF registers
(R92C_TSFTR(0), R92C_TSFTR(1), R92C_TSFTR(2)) which are 4 byte
control transfers. They take up valuable USB link time.

It's likely much less expensive for PCIe adapters. At some point
it may be worthwhile enabling it by default just for those.

With this disabled, the only USB traffic that I see during
normal data operation are bulk TX/RX data transfers for 802.11
packets, and on NICs w/ net80211 rate control, the control register
space read/writes for TX completion. (And that will also need
addressing.)

This is the difference between 15mbit TCP RX and 30mbit TCP RX
on the 11n NICs, and around 40 to 50mbit TCP RX on the 11ac NICs
in HT40 and VHT80.

Locally tested:

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

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

show more ...

rtwn: remove the conditional compilation around the sc_ht40 option.

This option stems from a bunch of issues a long time ago where HT40
support on some NICs is unstable - likely because we're not se

rtwn: remove the conditional compilation around the sc_ht40 option.

This option stems from a bunch of issues a long time ago where HT40
support on some NICs is unstable - likely because we're not setting
up the RF/baseband correctly.

In any case, it doesn't need to be conditionally compiled anymore.
Leave it in, leave it off by default, and various chipset initialisation
paths can decide whether to enable it themselves.

Reviewed by: emaste

show more ...

rtwn: change the USB TX transfers to only do one pending transfer per endpoint

I found I was getting constant device timeouts when doing anything
more complicated than a single SSH on laptop with RT

rtwn: change the USB TX transfers to only do one pending transfer per endpoint

I found I was getting constant device timeouts when doing anything
more complicated than a single SSH on laptop with RTL8811AU.

After digging into it, i found a variety of fun situations, including
traffic stalls that would recover w/ a shorter (1 second) USB transfer
timeout. However, the big one is a straight up hang of any TX endpoint
until the NIC was reset. The RX side kept going just fine; only the
TX endpoints would hang.

Reproducing it was easy - just start up a couple of traffic streams
on different WME AC's - eg a best effort + bulk transfer, like
browsing the web and doing an ssh clone - throw in a ping -i 0.1
to your gateway, and it would very quickly hit device timeouts every
couple of seconds.

I put everything into a single TX EP and the hangs went away.
Well, mostly.

So after some MORE digging, I found that this driver isn't checking
if the transfers are going into the correct EPs for the packet
WME access category / 802.11 TID; and would frequently be able
to schedule multiple transfers into the same endpoint.

Then there's a second problem - there's an array of endpoints
used for setting up the USB device, with .endpoint = UE_ADDR_ANY,
however they're also being setup with the same endpoint configured
in multiple transfer configs. Eg, a NIC with 3 or 4 bulk TX endpoints
will configure the BK and BE endpoints with the same physical endpoint
ID. This also leads to timed out transfers.

My /guess/ was that the firmware isn't happy with one or both of the
above, and so I solved both.

* drop the USB transfer timeout to 1 second, not 5 seconds -
that way we'll either get a 1 second traffic pause and USB transfer
failure, or a 5 second device timeout. Having both the TX timeout
and the USB transfer timeout made recovery from a USB transfer
timeout (without a NIC reset) almost impossible.

* enforce one transfer per endpoint;
* separate pending/active buffer tracking per endpoint;
* each endpoint now has its own TX callback to make sure the queue /
end point ID is known;
* and only frames from a given endpoint pending queue is going
into the active queue and into that endpoint.
* Finally, create a local wme2qid array and populate it with the
endpoint mapping that ensures unique physical endpoint use.

Locally tested:

* rtl8812AU, 11n STA mode
* rtl8192EU, 11n STA mode (with diffs to fix the channel config / power
timeouts.)

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

show more ...

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

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

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

MFHead@r345275

MFhead@r344996

Fix ieee80211_radiotap(9) usage in wireless drivers:

- Alignment issues:
* Add missing __packed attributes + padding across all drivers; in
most places there was an assumption that padding will be

Fix ieee80211_radiotap(9) usage in wireless drivers:

- Alignment issues:
* Add missing __packed attributes + padding across all drivers; in
most places there was an assumption that padding will be always
minimally suitable; in few places - e.g., in urtw(4) / rtwn(4) -
padding was just missing.
* Add __aligned(8) attribute for all Rx radiotap headers since they can
contain 64-bit TSF timestamp; it cannot appear in Tx radiotap headers, so
just drop the attribute here. Refresh ieee80211_radiotap(9) man page
accordingly.

- Since net80211 automatically updates channel frequency / flags in
ieee80211_radiotap_chan_change() drop duplicate setup for these fields
in drivers.

Tested with Netgear WG111 v3 (urtw(4)), STA mode.

MFC after: 2 weeks

show more ...

MFhead@r320180

Merge ^/head r319973 through 321382.

Merge ^/head r320573 through r320970.

rtwn_usb: reject too long (>16K) mbufs.

While here move RTWN_TXBUFSZ constant from common to USB specific code
(it's not used anywhere else).

MFhead@r313243

Merge ^/head r312624 through r312719.

Add support for the Realtek RTL8192EU chipset.
Committed over the D-Link DWA-131 rev E1 on amd64 with WPA.

Reviewed by: avos

Merge ^/head r312309 through r312623.

rtwn: export more stats to net80211

Setup more ieee80211_rx_stats fields for received frames:
- pktflags:
* IEEE80211_RX_F_FAIL_FCSCRC;
* IEEE80211_RX_F_AMPDU;
* IEEE80211_RX_F_AMPDU_MORE;

rtwn: export more stats to net80211

Setup more ieee80211_rx_stats fields for received frames:
- pktflags:
* IEEE80211_RX_F_FAIL_FCSCRC;
* IEEE80211_RX_F_AMPDU;
* IEEE80211_RX_F_AMPDU_MORE;
* IEEE80211_RX_F_SHORTGI;
- rate flags (CCK, OFDM, HT);
- width;
- phytype;
- rate;
- rx_tsf;
- rssi;
- nf;
- ieee, freq (RTL8188EU only, when ht40 support is disabled).

Tested with:
- RTL8188CE, RTL8188EU, RTL8821AU (STA / AP modes, i386)
- (by kevlo) RTL8188EU and RTL8812AU (amd64)

Reviewed by: adrian (previous version), kevlo
Differential Revision: https://reviews.freebsd.org/D9021

show more ...

Merge ^/head r311692 through r311807.