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
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
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
* 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)
* 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)
upstream it seems).
The tlv variable was changed to a pointer but the advancement of the data pointer
was left as sizeof(tlv). While the sizeof the (now) pointer equals the
sizeof 2 x uint32_t (size of the struct) on 64bit platforms, on 32bit platforms
the size of the advancement of the data pointer was wrong leading to
firmware load issues.
Correctly advance the data pointer by the size of the structure and not by
the size of a pointer.
PR: 219683
Submitted by: waddlesplash gamil.com (Haiku) on irc
MFC after: 1 week
arguments wrong in r339020.
PR: 231625
Reported by: Yuri Pankov (yuripv yuripv.net)
Reviewed by: cem, Yuri Pankov (yuripv yuripv.net)
Approved by: re (kib)
Pointyhat to: bz (a rather big one for this one)
This removes the direct WME info access in the ieee80211com struct and instead
provides a method of fetching the data. Right now it's a no-op but eventually
it'll turn into a per-VAP method for drivers that support it (eg iwn, iwm,
upcoming ath10k work) as things like p2p support require this kind of behaviour.
Tested:
* ath(4), STA and AP mode
TODO:
* yes, this is slightly stack size-y, but it is an important first step
to get drivers migrated over to a sensible WME API. A lot of per-phy things
need to be converted to per-VAP before P2P, 11ac firmware, etc stuff shows up.