This brings it inline with what's in openbsd. I tested it locally
with 2G and 5G association; it seems to work.
Tested: Intel 7260 AC, hw 0x140, STA mode, 2G/5G
Differential Revision: https://reviews.freebsd.org/D32627
Subscribers: imp
Obtainde from: OpenBSD
Summary:
This updates the if_iwmreg.h definitions to;
OpenBSD: if_iwmreg.h,v 1.65 2021/10/11 09:03:22 stsp Exp
A few things haven't been fully converted, namely:
* I left a couple things as enums for now just to reduce the
other diffs needed; but they're the same values
* The IWM_SCD_QUEUE_* macros have different offsets which I
didn't update in case they broke things / changed based on later
firmware. But they also may be real bugfixes which are needed
for later chips. It'll need more testing before flipping this on.
The c file updates are:
* Use the newer names for things if the name changed but the semantics
didn't
* Explicitly use the earlier firmware structs which maintain compat
with the current firmware and code. The newer ones are in here and
they'll get converted when more openbsd code is merged into this tree.
* Use the older iwm rate table for now, which has entries for legacy
rates, HT and VHT. Our code works with that right now, updating it
to openbsd's err, "different" version can be done at a later date
when HT/VHT support is added.
Notably, a bunch of definitions were deleted that weren't used.
They're not used either in the openbsd/dfbsd drivers so I think it's
safe to delete them in the long run.
Test Plan: 7260 hw 0x140
Subscribers: imp
Differential Revision: https://reviews.freebsd.org/D32627
Reviewed by: md5
Obtained From: OpenBSD
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
In r365419 ieee80211_media_change() callers were updated to not longer
act on the obselete ENETRESET return code.
While in the old days iwm has done a stop/init cycle in these cases,
this was not executed since r193340.
As a consequence simplify iwm code as well by passing ieee80211_media_change()
right to ieee80211_vap_attach() as there is no more need for a local
implementation.
Reported by: Tomoaki AOKI (junchoon dec.sakura.ne.jp)
Tested by: Tomoaki AOKI (junchoon dec.sakura.ne.jp)
MFC after: 3 days
X-MFC: fix is already in stable/12
PR: 248955
In r178354 with the introduction of multi-bss ("vap") support factoring
out started and with r193340 ieee80211_media_change() no longer returned
ENETRESET but only 0 or error.
As ieee80211(9) tells the ieee80211_media_change() function should not
be called directly but is registered with ieee80211_vap_attach() instead.
Some drivers have not been fully converted. After fixing the return
checking some of these functions were simply wrappers between
ieee80211_vap_attach() and ieee80211_media_change(), so remove the extra
function, where possible as well.
PR: 248955
Submitted by: Tong Zhang (ztong0001 gmail.com) (original)
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Previously the driver handled the bit within itself, but did not expose
the state change to net80211 and interface layers.
This change uses net80211 KPI for rfkill signaling.
The code is modeled after similar code in iwn and wpi.
Reviewed by: adrian
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D24923
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
This was inherited from iwlwifi, which drives devices supported by both
iwn(4) and iwm(4) in FreeBSD. In iwm(4) _mvm is meaningless, so remove
it. OpenBSD made the same change a long time ago. No functional change
intended.
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
This is what iwlwifi seems to do, and the previous behaviour triggered
firmware panics during transmit on a 9560.
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Though we don't otherwise use firmware's offload capabilities, we need
to set this flag when the MAC header's size isn't a multiple of four.
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
- Configure the scheduler only for the management queue.
- Fix a bug when enabling the schduler: the queues are specified using a
bitmask.
- Fix style in the area.
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
This is the multiqueue receive code required for 9000-series chips.
Note that we still only configure a single RX queue for now. Multiqueue
support will require MSI-X configuration and a scheme for managing a
global pool of RX buffers.
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
For now iwm only ever uses queue 0 and the management queue, but my 9560
raises a software error interrupt during initialization if this flag is
not set. iwlwifi sets it for all 7000- and 8000-series hardware, so we
might as well do it unconditionally.
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
The firmware for 9000-series and newer devices has a different receive
API which supports multiple queues.
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Match such chips using the device ID. We should really be checking the
subdevice as well, since a smaller number of 9460 and 9560 devices
actually belong to a new series of devices and require different
firmware, but that will require some extra logic in iwm_attach().
Submitted by: lwhsu, Guo Wen Jun <blockk2000@gmail.com>
MFC after: 2 weeks
Convert existing device family checks to avoid assuming that the device
family is always one of IWM_DEVICE_FAMILY_7000 or _8000.
Submitted by: lwhsu, Guo Wen Jun <blockk2000@gmail.com>
MFC after: 2 weeks
Only perform the call when a qfull bit transitions. While here, avoid
assignments in declarations in iwm_mvm_rx_tx_cmd().
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
This ensures that the driver softc reflects device capabilities as early
as possible, for use by device initialization code that is conditional
on certain capabilities.
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Also ensure that the htole* macros are applied correctly when specifying
the segment length and upper address bits. No functional change
intended (unless you use iwm(4) on a big-endian machine).
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Otherwise there is a window where they may be rescheduled. This
typically manifested as a page fault shortly after unloading if_iwm.ko.
Close the race by draining callouts after calling iwm_stop_device(),
which is also what Dragonfly does.
Change whitespace to reduce gratuitous diffs with Dragonfly.
Reported and tested by: seanc
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
This allows replacing "sys/eventfilter.h" includes with "sys/_eventfilter.h"
in other header files (e.g., sys/{bus,conf,cpu}.h) and reduces header
pollution substantially.
EVENTHANDLER_DECLARE and EVENTHANDLER_LIST_DECLAREs were moved out of .c
files into appropriate headers (e.g., sys/proc.h, powernv/opal.h).
As a side effect of reduced header pollution, many .c files and headers no
longer contain needed definitions. The remainder of the patch addresses
adding appropriate includes to fix those files.
LOCK_DEBUG and LOCK_FILE_LINE_ARG are moved to sys/_lock.h, as required by
sys/mutex.h since r326106 (but silently protected by header pollution prior
to this change).
No functional change (intended). Of course, any out of tree modules that
relied on header pollution for sys/eventhandler.h, sys/lock.h, or
sys/mutex.h inclusion need to be fixed. __FreeBSD_version has been bumped.
Intel 3168 uses another EEPROM section to store channel flags;
port missing bits from iwlwifi to make it work.
PR: 230750, 236235
Tested by: Bert JW Regeer <xistence@0x58.com>
MFC after: 3 days
- 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
* There's no reason to have a while() loop here, because:
- if msleep returns 0, that means we were woken up by the interrupt handler,
and we are going to exit immediately as sc_fw_chunk_done will now be 1
(there is nothing else that sleeps on sc_fw.)
- if msleep doesn't return 0 (i.e. it returned ETIMEDOUT) then we will
exit immediately because of the if-test.
So, just use a single msleep() and then check sc_fw_chunk_done as before.
* The comment said we were sleeping for 5 seconds, but the msleep was only
for 1. Before r314065, this was 1 second and so was the comment,
and in that commit the comment was changed and the function call wasn't.
Possibly fixes failures to initialize uCode on certain devices.
Submitted by: Augustin Cavalier (waddlesplash gmail.com)
Obtained from: Haiku 132990ecdcb072f2ce597b5d497ff3e5b1f09c20
MFC after: 10 days
