Both rwlwifi in Linux and rtwn in OpenBSD restore this register,
and the existing code was saving the value and not using it.
Reported by: -Wunused-but-set-variable
Reviewed by: imp
Obtained from: OpenBSD
Differential Revision: https://reviews.freebsd.org/D34838
According to information found on the internet the following products
use exactly the same hardware but probably different USB IDs:
- Edimax EW-7811Un V2 (v2)
- Edimax EW-7811GLN 2.0A (v2)
I am not adding them as I cannot verify.
PR: 254280
MFC after: 1 week
While IEEE80211_R_BAND was defined, there was no place to store the
band. Add a field for that, adjust ieee80211_lookup_channel_rxstatus()
to require it, and update drivers passing "R_{FREQ|IEEE}" in already to
provide the band as well. For the moment keep the fall-back code
requiring all three fields.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D30662
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
Rather than placing the epoch around the entire receive loop which
might call into rtwn_rx_frame() and USB and sleep, split the loop
into two[1] and leave us with one unlock/lock cycle as well.
PR: 249925
Reported by: thj, (rkoberman gmail.com)
Tested by: thj
Suggested by: adrian [1]
Reviewed by: adrian
MFC after: 3 days
Sponsored by: The FreeBSD Foundation (initially, paniced my iwl lab host)
Differential Revision: https://reviews.freebsd.org/D26554
For ieee80211_add_channel+*() we are passing in an int flag for
ht40 and in some cases another int flag for vht80 where we'd only
need two bits really.
Convert these variables to a bitflag and fold them together into one.
This also allows for VHT160 and VHT80P80 and whatever may come to
be considered. Define the various options currently needed.
Change the drivers (rtwn and rsu) which actually set this bit to non-0.
For convenience the "1" currently used for HT40 is preserved.
Enahnce getflags_5ghz() to handle the full set of VHT flags based
on the input flags from the the driver.
Update the regdomain implementation as well to make use of the new
flags and deal with higher [V]HT bandwidths.
ieee80211_add_channel() specifically did not take flags so it will
not support naything beyond 20Mhz channels.
Note: I am not entirely happy with the "cbw_flag[s]" name, but we
do use chan_flags elsewhere already.
MFC after: 2 weeks
Reviewed by: adrian, gnn
Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate")
Differential revision: https://reviews.freebsd.org/D26091
Make sure all occurrences of ieee80211_input_xxx() in sys/dev are
covered by a network epoch section. Do not depend on the interrupt
handler nor any taskqueues being in a network epoch section.
This patch should unbreak the PCI WLAN drivers after r357004.
Pointy hat: glebius@
Sponsored by: Mellanox Technologies
- 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
- 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
Wrap ieee80211_add_channel_list_2ghz into another function
which supplies default (1-14) channel list to it and drop
its copies from drivers.
Checked with RTL8188EE, country US / JP / KR / UA.
MFC after: 2 weeks
Replace in-place implementation with system-wide one; since it
guarantees non-zero result drop all less-than-one checks from
drivers and net80211.
MFC after: 2 weeks
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
The code is similar to the one for RTL8188E* and probably
should be shared with RTL8188CE (needs to be tested).
Checked with RTL8188CUS, STA mode.
MFC after: 5 days