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
* This hopefully avoids some firmware panics, I was occasionally seeing,
when iwm disconnects upon losing signal to an access point at some point.
* This is synchronizing the if_iwm_time_event.c file a bit more from the
corresponding Linux iwlwifi/mvm/time-event.c.
Taken-From: Linux iwlwifi
Submitted by: Augustin Cavalier <waddlesplash@gmail.com> (Haiku)
Obtained from: DragonFlyBSD (e8cb71584a6a72232c13151d60e57f7f229220eb)
* This is a mix of the OpenBSD Git 7fd9664469d1b717a307eebd74aeececbd3c41cc
change, and syncing with the Linux iwlwifi code.
Taken-From: Linux iwlwifi, and OpenBSD
Submitted by: Augustin Cavalier <waddlesplash@gmail.com> (Haiku)
Obtained from: DragonFlyBSD (706a3044afd27c3fecfdf57bec1695310e53e228)
* This avoids firmware resets in all the cases in iwm_newstate(). Instead
iwm_bring_down_firmware() is called, which tears down all the STA
connection state, according to the sc->sc_firmware_state value.
* Improve the behaviour of the LED blinking a bit, so it only blinks when
there really is a wireless scan going on.
* Print the newstate arg in debug output of iwm_newstate(), to help in
debugging.
This is inspired by the firmware state maintaining change in OpenBSD's iwm,
by stsp@openbsd.org (OpenBSD Git 0ddb056fb7370664b1d4b84392697cb17d1a414a).
Submitted by: Augustin Cavalier <waddlesplash@gmail.com> (Haiku)
Obtained from: DragonFlyBSD (8a41b10ac639d0609878696808387a6799d39b57)
* While there remove unused IWM_UCODE_TLV_CAPA_LMAC_UPLOAD definition,
which isn't defined in iwlwifi.
Taken-From: Linux iwlwifi
Submitted by: Augustin Cavalier <waddlesplash@gmail.com> (Haiku)
Obtained from: DragonFlyBSD (fd4f9de8bc72ea961e50829b45b59d0549040b7d)
* Remove outdated notifications IWM_SCAN_ABORT_CMD,
IWM_SCAN_START_NOTIFICATION and IWM_SCAN_RESULTS_NOTIFICATION.
* Remove unused enum iwm_scan_complete_status.
* Use the updated FW Api version 3 of struct iwm_scan_results_notif.
* No functional change, since struct iwm_scan_results_notif is never
accessed in iwm at the moment.
Taken-From: Linux iwlwifi commits 1083fd7391e989be52022f0f338e9dadc048b063
and 75118fdb63496e4611ab50380499ddd62b9de69f.
Submitted by: Augustin Cavalier <waddlesplash@gmail.com> (Haiku)
Obtained from: DragonFlyBSD (c947b0b8dc96dabefd63f7b70d53695e36c7b64f)
* Rename some structs and struct members for firmware handling.
Submitted by: Augustin Cavalier <waddlesplash@gmail.com> (Haiku)
Obtained from: DragonFlyBSD (4b1006a6e4d0f61d48c67b46e1f791e30837db67)
* There is (almost) nothing to do in suspend/resume if if_iwm has failed
during initialization (e.g. because of firmware load failure) and was
already uninitialized by iwm_detach_local().
Submitted by: Augustin Cavalier <waddlesplash@gmail.com> (Haiku)
Obtained from: DragonFlyBSD (67b5e090efb225654815fed91020db6cfc16bb19)
* We should load the firmware exactly once before the driver really
initializes the hardware the first time, and unload it at detach time.
There is no need to retrieve the firmware during execution of
iwm_mvm_load_ucode_wait_alive(), we should make sure we already have the
firmware data at hand before that.
* The existing sc_preinit_hook code fails to deal with the case where
if_iwm is loaded by the loader (or is statically linked) and the
firmware needs to be loaded from disk. So we can just call
iwm_read_firmware() from iwm_attach() directly.
* A separate solution will have to be added to properly defer the firmware
loading during bootup, until the necessary filesystem is mounted.
Submitted by: Augustin Cavalier <waddlesplash@gmail.com> (Haiku)
Obtained from: DragonFlyBSD (0104ee1f4cb6a2313c00c2526c6ae98d42e5041d)
* Doing the iwm_prepare_card_hw() call in iwm_attach() only on Family 8000
hardware matches the code in Linux iwlwifi.
* While there remove DEFAULT_MAX_TX_POWER definition which is unused, and
has a value different from IWL_DEFAULT_MAX_TX_POWER in iwlwifi.
Submitted by: Augustin Cavalier <waddlesplash@gmail.com> (Haiku)
Obtained from: DragonFlyBSD (e8560f8dc58df12a7c79a6bb4e6ccb156e001085)
* Rather than providing a non-zero index into the firmware RS table,
we should always use index 0 and update the firmware RS table whenever
our chosen tx rate for data-frames changes.
* Send IWM_LQ_CMD updates when the tx rate gets updated by the net80211
rate control (which is after we tell the tx status to the net80211
rate-control in iwm_mvm_rx_tx_cmd_single()).
* Disregard frames transferred with a different tx rate than the currently
selected rate for the rate-control calculations. This way we avoid
counting management frames (which are sent at a slow, and fixed rate),
as well as frames we added to the tx queue just before a new IWM_LQ_CMD
update took effect.
Submitted by: Augustin Cavalier <waddlesplash@gmail.com> (Haiku)
Obtained from: DragonFlyBSD (5d6b465e288ac5b52d7115688d4e6516acbbea1c)
