| Age | Commit message (Collapse) | Author |
|---|
|
If no firmware was present at all (or, presumably, all of the
firmware files failed to parse), we end up unbinding by calling
device_release_driver(), which calls remove(), which then in
iwlwifi calls iwl_drv_stop(), freeing the 'drv' struct. However
the new code I added will still erroneously access it after it
was freed.
Set 'failure=false' in this case to avoid the access, all data
was already freed anyway.
Cc: stable@vger.kernel.org
Reported-by: Stefan Agner <stefan@agner.ch>
Reported-by: Wolfgang Walter <linux@stwm.de>
Reported-by: Jason Self <jason@bluehome.net>
Reported-by: Dominik Behr <dominik@dominikbehr.com>
Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Fixes: ab07506b0454 ("iwlwifi: fix leaks/bad data after failed firmware load")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220208114728.e6b514cf4c85.Iffb575ca2a623d7859b542c33b2a507d01554251@changeid
|
|
There's currently only one driver that reports CHECKSUM_COMPLETE,
that is iwlwifi. The current hardware there calculates checksum
after the SNAP header, but only RFC 1042 (and some other cases,
but replicating the exact hardware logic for corner cases in the
driver seemed awkward.)
Newer generations of hardware will checksum _including_ the SNAP,
which makes things easier.
To handle that, simply always assume the checksum _includes_ the
SNAP header, which this patch does, requiring to first add it
for older iwlwifi hardware, and then remove it again later on
conversion.
Alternatively, we could have:
1) Always assumed the checksum starts _after_ the SNAP header;
the problem with this is that we'd have to replace the exact
"what is the SNAP" check in iwlwifi that cfg80211 has.
2) Made it configurable with some flag, but that seemed like too
much complexity.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20220202104617.230736e19e0e.I3e6745873585ad943c152fab9e23b5221f17a95f@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
SAR GEO offsets are not supported on 3160 devices. The code was
refactored and caused us to start sending the command anyway, which
causes a FW assertion failure. Fix that only considering this feature
supported on FW API with major version is 17 if the device is not
3160.
Additionally, fix the caller of iwl_mvm_sar_geo_init() so that it
checks for the return value, which it was ignoring.
Reported-by: Len Brown <lenb@kernel.org>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Fixes: 78a19d5285d9 ("iwlwifi: mvm: Read the PPAG and SAR tables at INIT stage")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/iwlwifi.20220128144623.96f683a89b42.I14e2985bfd7ddd8a8d83eb1869b800c0e7f30db4@changeid
|
|
This feature has been deprecated and should not be used anymore. With
newer firmwares, namely *-67.ucode and above, trying to use it causes an
assertion failure in the FW, similar to this:
[Tue Jan 11 20:05:24 2022] iwlwifi 0000:04:00.0: 0x00001062 | ADVANCED_SYSASSERT
In order to prevent this feature from being used, remove it entirely
and get rid of the Kconfig option that
enables it (IWLWIFI_BCAST_FILTERING).
Fixes: cbaa6aeedee5 ("iwlwifi: bump FW API to 67 for AX devices")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215488
Cc: stable@vger.kernel.org # 5.16.x
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/iwlwifi.20220128144623.9241e049f13e.Ia4f282813ca2ddd24c13427823519113f2bbebf2@changeid
|
|
When we register and we are in link protection passive, meaning
that the host can't touch the device, report RFKILL immediately
upon register() and don't wait for the CSME firmware to let us
know again about the link protection state.
What happens if we wait is that the host will not see RFKILL soon
enough and we'll have a window of time during which it can bring
up the device which will request ownership.
Fixes: 2da4366f9e2c ("iwlwifi: mei: add the driver to allow cooperation with CSME")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/iwlwifi.20220128142706.a136f9f46336.Ief7506dc3b1813a1943a5a639aa45d8e5f284f31@changeid
|
|
iwlmei can trigger a hardware RFKILL when the CSME firmware
does not want the host to touch the device.
But then, iwlmvm reports RFKILL which makes cfg80211 update
iwlmvm about RFKILL. iwlmvm then thinks there is a change in
the _software_ rfkill and it calls rfkill_blocked() to fetch
the RFKILL state. This returns that RFKILL is blocked (because
of iwlmei) and iwlmvm tells iwlmei that _software_ RFKILL is
asserted.
This is a bug of course.
Fix this by checking explicitly the software RFKILL state and
not the overall RFKILL state.
Fixes: 7ce1f2157e14 ("iwlwifi: mvm: read the rfkill state and feed it to iwlmei")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Fixes: 7ce1f2157e14 ("iwlwifi: mvm: read the rfkill state and feed it to iwlmei")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/iwlwifi.20220128142706.f293861a3f92.I9553d27df1de6fd5756a43ea5f8b89d06fa1a6f2@changeid
|
|
The shared area is a DMA memory allocated in the host and
mapped so that the host and the CSME firmware can
exchange data. It is mapped through a dedicated PCI device
that is driven by the mei bus driver.
The bus driver is in charge of allocating and mapping this
memory. It also needs to configure the CSME firmware with
a specific set of commands, so that the CSME firmware will
know that this memory is meant to be used by its internal
WLAN module.
For this, the CSME firmware first needs to completely
initialize its WLAN module and only then get the mapping
request.
The problem is that the mei bus enumeration completes
before the WLAN is completely ready. This means that
the WLAN module's initialization is racing with iwlmei's
allocation and mapping flow.
Testing showed a problem in resume flows where iwlmei
was too fast and the DMA mapping failed.
Add a retry mechanism to make sure that we will succeed
to map the memory.
Fixes: 2da4366f9e2c ("iwlwifi: mei: add the driver to allow cooperation with CSME")
Fixes: bcbddc4f9d02 ("iwlwifi: mei: wait before mapping the shared area")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/iwlwifi.20220128142706.cc51e6a6d635.I4b74a082eb8d89f9e4f556a27c4339c15444dc6c@changeid
|
|
The check makes sure that we can look at the ip header.
We first need to check that the basic ip header (20 bytes)
can be pulled before we look at the field that will teach
us how long is the ip header. This is why there are two
checks.
The second check was wrong and smatch pointed that
sizeof(ip_hdrlen(skb) - sizeof(*iphdr)) can't be right.
Looking at the code again made me think that we really
need ip_hdrlen(skb) since we want to make sure all the
IP header is in the buffer header. This will allow us
to set the transport offset and from there to look
at the transport header (TCP / UDP).
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Fixes: 2da4366f9e2c ("iwlwifi: mei: add the driver to allow cooperation with CSME")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/iwlwifi.20220128142706.6d9fcf82691e.I449b1e21c5b5478f2ac218522570479918f49f9d@changeid
|
|
If we run into this error path, we shouldn't unlock the mutex
since it's not locked since. Fix this in the gen2 code as well.
Fixes: eda50cde58de ("iwlwifi: pcie: add context information support")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/iwlwifi.20220128142706.b8b0dfce16ef.Ie20f0f7b23e5911350a2766524300d2915e7b677@changeid
|
|
If we run into this error path, we shouldn't unlock the mutex
since it's not locked since. Fix this.
Fixes: a6bd005fe92d ("iwlwifi: pcie: fix RF-Kill vs. firmware load race")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/iwlwifi.20220128142706.5d16821d1433.Id259699ddf9806459856d6aefbdbe54477aecffd@changeid
|
|
There are a couple of bugs in this function:
1. It is declared as a non-static function, even though
it's only used in one file.
2. Its return value should be of type u32 but it returns
(in some cases) -1.
Fix them by making this function static and returning an
error value of type unsigned.
In addition, we're assigning the return value of this function
as the legacy rate even if the function returned an error value.
Fix this by assigning the lowest rate in this case.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reported-by: Ye Guojin <ye.guojin@zte.com.cn>
Reported-by: Zeal Robot <zealci@zte.com.cn>
Fixes: 9998f81e4ba5 ("iwlwifi: mvm: convert old rate & flags to the new format.")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/iwlwifi.20220128142706.5612eeb9d6d0.I992e10d93fc22919b2bc42daad087ee1b5d6f014@changeid
|
|
We're checking the FW version of TX_CMD in order to decide whether to
convert rate_n_flags from the old format to the new one. If the API
is smaller or equal to 6 we should convert it. Currently we're
converting if the API version is greater than 6. Fix it.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Fixes: dc52fac37c87 ("iwlwifi: mvm: Support new TX_RSP and COMPRESSED_BA_RES versions")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/iwlwifi.20220128142706.a264ac51d106.I228ba1317cdcbfef931c09d280d701fcad9048d2@changeid
|
|
When building ARCH=arm allmodconfig:
drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c: In function ‘iwl_mvm_ftm_rtt_smoothing’:
./include/asm-generic/div64.h:222:35: error: comparison of distinct pointer types lacks a cast [-Werror]
222 | (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
| ^~
drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c:1070:9: note: in expansion of macro ‘do_div’
1070 | do_div(rtt_avg, 100);
| ^~~~~~
do_div() has to be used with an unsigned 64-bit integer dividend but
rtt_avg is a signed 64-bit integer.
div_s64() expects a signed 64-bit integer dividend and signed 32-bit
divisor, which fits this scenario, so use that function here to fix the
warning.
Fixes: 8b0f92549f2c ("iwlwifi: mvm: fix 32-bit build in FTM")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20211227191757.2354329-1-nathan@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:
====================
wireless-drivers-next patches for v5.17
Third set of patches for v5.17, and the final one if all goes well. We
have Specific Absorption Rate (SAR) support for both mt76 and rtw88.
Also iwlwifi should be now W=1 warning free. But otherwise nothing
really special this time, business as usual.
Major changes:
mt76
* Specific Absorption Rate (SAR) support
* mt7921: new PCI ids
* mt7921: 160 MHz channel support
iwlwifi
* fix W=1 and sparse warnings
* BNJ hardware support
* add new killer device ids
* support for Time-Aware-SAR (TAS) from the BIOS
* Optimized Connectivity Experience (OCE) scan support
rtw88
* hardware scan
* Specific Absorption Rate (SAR) support
ath11k
* qca6390/wcn6855: report signal and tx bitrate
* qca6390: rfkill support
* qca6390/wcn6855: regdb.bin support
ath5k
* switch to rate table based lookup
wilc1000
* spi: reset/enable GPIO support
* tag 'wireless-drivers-next-2021-12-23' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next: (148 commits)
mt76: mt7921: fix a possible race enabling/disabling runtime-pm
wilc1000: Document enable-gpios and reset-gpios properties
wilc1000: Add reset/enable GPIO support to SPI driver
wilc1000: Convert static "chipid" variable to device-local variable
rtw89: 8852a: correct bit definition of dfs_en
rtw88: don't consider deep PS mode when transmitting packet
ath11k: Fix unexpected return buffer manager error for QCA6390
ath11k: add support of firmware logging for WCN6855
ath11k: Fix napi related hang
ath10k: replace strlcpy with strscpy
rtw88: support SAR via kernel common API
rtw88: 8822c: add ieee80211_ops::hw_scan
iwlwifi: mei: wait before mapping the shared area
iwlwifi: mei: clear the ownership when the driver goes down
iwlwifi: yoyo: fix issue with new DBGI_SRAM region read.
iwlwifi: fw: fix some scan kernel-doc
iwlwifi: pcie: make sure prph_info is set when treating wakeup IRQ
iwlwifi: mvm: remove card state notification code
iwlwifi: mvm: drop too short packets silently
iwlwifi: mvm: fix AUX ROC removal
...
====================
Link: https://lore.kernel.org/r/20211223141108.78808C36AE9@smtp.kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Commit d068ca2ae2e6 ("codel: split into multiple files") moved all
Qdisc-related code to codel_qdisc.h, move the include of pkt_sched.h
as well.
This is similar to the previous commit, although we don't care as
much about incremental builds after pkt_sched.h was touched itself
it is included by net/sch_generic.h which is modified ~20 times
a year.
This decreases the incremental build size after touching pkt_sched.h
from 1592 to 617 objects.
Fix unmasked missing includes in WiFi drivers.
Acked-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211221193941.3805147-2-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next
wlwifi patches for v5.17 v2
* Support for Time-Aware-SAR (TAS) as read from the BIOS;
* Fix scan timeout issue when 6GHz is enabled;
* Work continues for new HW family Bz;
* Support for Optimized Connectivity Experience (OCE) scan;
* A bunch of FW debugging improvements and fixes;
* Fix one 32-bit compilation issue;
* Some RX changes for new HW family
* Some fixes for 6 GHz scan;
* Fix SAR table fixes with newer platforms;
* Fix early restart crash;
* Small fix in the debugging code;
* Add new Killer device IDs;
* Datapath updates for Bz family continues;
* A couple of important fixes in iwlmei;
* Some other small fixes, clean-ups and improvements.
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next
Johannes Berg says:
====================
This time we have:
* ndo_fill_forward_path support in mac80211, to let drivers use it
* association comeback notification for userspace, to be able
to react more sensibly to long delays
* support for background radar detection hardware in some chipsets
* SA Query Procedures offload on the AP side
* more logging if we find problems with HT/VHT/HE
* various cleanups and minor fixes
Conflicts:
net/wireless/reg.c:
e08ebd6d7b90 ("cfg80211: Acquire wiphy mutex on regulatory work")
701fdfe348f7 ("cfg80211: Enable regulatory enforcement checks for drivers supporting mesh iface")
https://lore.kernel.org/r/20211221111950.57ecc6a7@canb.auug.org.au
drivers/net/wireless/ath/ath10k/wmi.c:
7f599aeccbd2 ("cfg80211: Use the HE operation IE to determine a 6GHz BSS channel")
3bf2537ec2e3 ("ath10k: drop beacon and probe response which leak from other channel")
https://lore.kernel.org/r/20211221115004.1cd6b262@canb.auug.org.au
* tag 'mac80211-next-for-net-next-2021-12-21' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next: (32 commits)
cfg80211: Enable regulatory enforcement checks for drivers supporting mesh iface
rfkill: allow to get the software rfkill state
cfg80211: refactor cfg80211_get_ies_channel_number()
nl82011: clarify interface combinations wrt. channels
nl80211: Add support to offload SA Query procedures for AP SME device
nl80211: Add support to set AP settings flags with single attribute
mac80211: add more HT/VHT/HE state logging
cfg80211: Use the HE operation IE to determine a 6GHz BSS channel
cfg80211: rename offchannel_chain structs to background_chain to avoid confusion with ETSI standard
mac80211: Notify cfg80211 about association comeback
cfg80211: Add support for notifying association comeback
mac80211: introduce channel switch disconnect function
cfg80211: Fix order of enum nl80211_band_iftype_attr documentation
cfg80211: simplify cfg80211_chandef_valid()
mac80211: Remove a couple of obsolete TODO
mac80211: fix FEC flag in radio tap header
mac80211: use coarse boottime for airtime fairness code
ieee80211: change HE nominal packet padding value defines
cfg80211: use ieee80211_bss_get_elem() instead of _get_ie()
mac80211: Use memset_after() to clear tx status
...
====================
Link: https://lore.kernel.org/r/20211221112532.28708-1-johannes@sipsolutions.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The shared area is a DMA memory allocated in the host and
mapped so that the host and the CSME firmware can
exchange data. It is mapped through a dedicated PCI device
that is driven by the mei bus driver.
The bus driver is in charge of allocating and mapping this
memory. It also needs to configure the CSME firmware with
a specific set of commands, so that the CSME firmware will
know that this memory is meant to be used by its internal
WLAN module.
For this, the CSME firmware first needs to completely
initialize its WLAN module and only then get the mapping
request.
The problem is that the mei bus enumeration completes
before the WLAN is completely ready. This means that
the WLAN module's initialization is racing with iwlmei's
allocation and mapping flow.
Testing showed a problem in resume flows where iwlmei
was too fast and the DMA mapping failed.
Add a delay to avoid this. This is still racy, but our
measurements showed that we have a good margin and we
should now be safe.
Fixes: 2da4366f9e2c ("iwlwifi: mei: add the driver to allow cooperation with CSME")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211220142940.8b6279e3d0be.I6fe128b0b86149a85535104822c8355b367887c8@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
When the driver is unregistered, CSME will take ownership on the
device. Reflect this in the iwlmei object so that we will remember
to re-ask for ownership when the driver will register again.
Not doing so will cause CSME not to give the host ownership and
we will see the following error message when trying to bring up
the interface:
iwlwifi 0000:a9:00.0: iwl_pcie_prepare_card_hw iwl_trans_prepare_card_hw enter
iwlwifi 0000:a9:00.0: iwl_pcie_set_hw_ready hardware not ready
iwlwifi 0000:a9:00.0: iwl_pcie_set_hw_ready hardware not ready
iwlwifi 0000:a9:00.0: iwl_pcie_prepare_card_hw Couldn't prepare the card but SAP is connected
iwlwifi 0000:a9:00.0: Error while preparing HW: -16
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211220142940.c7bb5b7644df.I48498d9fd6e3959562205af67aa5f1a822eb762d@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
NIC has been grabbed for reading twice which is leading
to NIC hang. Code correction are done for reading data with
no grab function.
Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219132536.55527214f8c9.I1748215ccb3fa20a3491a46a49b12e04eb560ac6@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Some devices also use iwl_scan_config_v2 struct, so link it in
the documentation for SCAN_CFG_CMD. Fix a bunch of kernel-doc
as well.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219132536.3331df94b106.If6c96b0d386e1c5988c8da6b69257e8f2e737f07@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
In some rare cases when the HW is in a bad state, we may get this
interrupt when prph_info is not set yet. Then we will try to
dereference it to check the sleep_notif element, which will cause an
oops.
Fix that by ignoring the interrupt if prph_info is not set yet.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219132536.0537aa562313.I183bb336345b9b3da196ba9e596a6f189fbcbd09@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
This notification ID was actually used for something else we
never implemented, but luckily we only had some debug code
here. Just remove it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219132536.a67b5b9db259.Ic55b306fcd2a3525b3993f4b7e00622dd95053ba@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
There's little value in this warning, we get a warning here
if firmware passes us a short packet, particularly in monitor
mode.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219132536.305d12cf51ac.I2e4e6874113b1e5d8ee467b8a2d90820cc6ddde9@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
When IWL_UCODE_TLV_CAPA_SESSION_PROT_CMD is set, removing a time event
always tries to cancel session protection. However, AUX ROC does
not use session protection so it was never removed. As a result,
if the driver tries to allocate another AUX ROC event right after
cancelling the first one, it will fail with a warning.
In addition, the time event data passed to iwl_mvm_remove_aux_roc_te()
is incorrect. Fix it.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219132536.915e1f69f062.Id837e917f1c2beaca7c1eb33333d622548918a76@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Currently we always return the op_mode with valid pointer in case
getting NVM failed, while it's only relevant for cases that CSME is the
owner of the nic.
Fix this by checking also who's the owner of the nic.
Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219132536.b1e96021b616.Id0164855f2dd01ecdecf79b239d6ee5974882245@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Support TX checksum offload for Bz devices, where we have full
checksum offload (NETIF_F_HW_CSUM) and the hardware doesn't
need to parse the IP headers or anything.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219132536.c0f44c98b36d.I75a688f3ac80cbe824c459ece4bb67843b9fce76@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
If OEM isn't in the allowed list, TAS should be disabled in US/CA.
Currently, if the OEM isn't allowed - we're sending the TAS only
if we are not in US or CA.
But this country check is done before we even know the country
(usually the configuration is ZZ in that stage).
So do the following instead:
1. Check if the current OEM is in the allowed list
2. If not - add US and CA to tas_block_list_array
3. Send the TAS table to FW.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Set scan offload profiles auth algorithms with valid
algorithms only.
Signed-off-by: Ayala Beker <ayala.beker@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219132536.525f2d468d22.I4d497d6a0a14ffb833f7edc7e980d26bbf8d7527@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Don't use protected ranging negotiation for FTM ranging as responders
that support only FTM ranging don't expect the FTM request to be
protected.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Fixes: 517a5eb9fab2 ("iwlwifi: mvm: when associated with PMF, use protected NDP ranging negotiation")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219132536.f50ed0e3c6b3.Ibff247ee9d4e6e0a1a2d08a3c8a4bbb37e6829dd@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
add killer subsystem devices from the 1675i and 1675s family
to the driver.
Signed-off-by: Yaara Baruch <yaara.baruch@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219132536.2d5bec2d7b68.Icffb4e27390e6a5c76a0cbe7abf7472558f323d6@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
The 6GHz passive scan is performed only once every 50 minutes.
However, in case of suspend/resume, the regulatory information
is reset, so 6GHz channels may become disabled.
Fix it by performing a 6GHz passive scan within 60 seconds after
suspend/resume even if the 50 minutes timeout did not expire yet.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Fixes: e8fe3b41c3a3 ("iwlwifi: mvm: Add support for 6GHz passive scan")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.6d5c043372cf.I251dd5618a3f0b8febbcca788eb861f1cd6039bc@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
In case of forced passive scan on a UHB channel,
don't set the direct probe option for this channel.
Signed-off-by: Ayala Beker <ayala.beker@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.0ede76a9ca92.Ie64a4df79ea9c485ae3d2fc043319e8f79cefa8e@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
In case of a conflict between BIOS version and FW
version of the PPAG table - the values arrive in the FW in the wrong
places. This happens because we're storing the table in different
structures depending on the BIOS version, not on the FW version,
and so the FW doesn't get what it expect to.
Always store the table in a v2 structure (which is a superset
of v1 and v0).
Also store the table in a structured way and in it's own structure,
rather then storing it in the ppag command structure, similarly to
the WRDS, EWRD and WGDS tables.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.793a509da7bd.Ia176746a28b816b5f788cce9a281139735909e2a@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Start supporting API version 69 for AX devices.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.7d8fe0dffaea.I2de65c1efd9ab464d4158a3d852f73efe63024f8@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
The RADA might include in the Rx frame the MIC and CRC bytes.
These bytes should be removed for non monitor interfaces and
should not be passed to mac80211.
Fix the Rx processing to remove the extra bytes on non monitor
cases.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.098be12c801e.I1d81733d8a75b84c3b20eb6e0d14ab3405ca6a86@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
In some cases the sta is being removed twice since we do not test the
roc aux running before removing it. Start looking at the bit before
removing the sta.
Signed-off-by: Nathan Errera <nathan.errera@intel.com>
Fixes: 2c2c3647cde4 ("iwlwifi: mvm: support ADD_STA_CMD_API_S ver 12")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.d5376ac6bcb0.Ic5f8470ea60c072bde9d1503e5f528b65e301e20@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
The FW API for PER_CHAIN_LIMIT_OFFSET_CMD is misleading. The element
name is table_rev, but it shouldn't actually contain the table
revision number, but whether we should use the South Korea scheme or
not.
Fix the driver so that we only set this value to either 0 or 1. It
will only be 1 (meaning South Korea) if the ACPI WGDS table revision
is 1.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Fixes: 664c011b763e ("iwlwifi: acpi: support reading and storing WGDS revision 2")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.abed3b8119c7.I1fdc2c14577523fcffdfe8fb5902c2d8efde7e09@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Support resetting the firmware via TLV-based debugging. When applied,
this will cause the driver to reset the firmware when the debugging
is triggered.
Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.d59b29653a1e.I7b3be4a1ad1a9d5d0e86259740e89ac113c9348b@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Increment the threshold to avoid dropping too eagerly.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.0e947ed458c4.Ia376cbea5f59df4b4474f0bd33ab033e84535cce@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
We don't really have much reason to mistrust the hardware
queue number, but if it gets mixed up we still don't want
to access some data out of bounds, so drop such frames.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.539aecb91247.I6e555a5185bad30d7d1a4659f9c0b99325425f18@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
On Bz devices, the hardware checksums including the SNAP header,
starting directly after the MAC header, so we don't need the
extra checks and can just pass the checksum to mac80211.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.8ef59da4e05e.Ide87c2dc8fa08eae55c013a625f4ece5184b1b63@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
For the upcoming Bz devices, we will set NETIF_F_HW_CSUM instead
of NETIF_F_IP_CSUM and NETIF_F_IPV6_CSUM. However, we still need
to be able to remove all the checksum bits, so add a mask for the
removal, and keep the old define for the feature advertisement.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219121514.f05488ce8b83.I65bb83721498d8433e4ee2b09415eb74ab579445@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
When CONFIG_DEBUG_TEST_DRIVER_REMOVE is set, iwlwifi crashes
when the opmode module cannot be loaded, due to completing
the completion before using drv->dev, which can then already
be freed.
Fix this by removing the (fairly useless) message. Moving the
completion later causes a deadlock instead, so that's not an
option.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/20211210091245.289008-2-luca@coelho.fi
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Isolate the entire calculation of the offload_assist field used
for HW checksumming to the iwl_mvm_tx_csum function.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211210110539.796ae29c90d9.Icb2f07905bebd9ed4537ca4c453069211ea71799@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
In case the fw supports OCE scan and one of the OCE feature flags
are set in the scan request, set the corresponding flag in the
firmware scan request.
Note that new firmware that indicates OCE support does not support
the probe deferral and suppression feature (which is optional).
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211210110539.3dd63c381839.Id79b39f650103bb9b851e31ed6a0178e81988587@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
If firmware load fails after having loaded some parts of the
firmware, e.g. the IML image, then this would leak. For the
host command list we'd end up running into a WARN on the next
attempt to load another firmware image.
Fix this by calling iwl_dealloc_ucode() on failures, and make
that also clear the data so we start fresh on the next round.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211210110539.1f742f0eb58a.I1315f22f6aa632d94ae2069f85e1bca5e734dce0@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Debug TLV parsing was missing size checks, so if a valid but
too short TLV was encountered, it would attempt to read it.
If the firmware file was arranged to be a multiple of pages
long with this happening just before the end, it could crash
reading out-of-bounds of a vmalloc area.
Fix this by adding the relevant size check.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211210110539.84848da8067f.Ifb4f80c95d283ec62e495a7928069af711b5fee2@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
On a 32-bit build, the division here needs to be done
using do_div(), otherwise the compiler will try to call
a function that doesn't exist, thus failing to build.
Fixes: b68bd2e3143a ("iwlwifi: mvm: Add FTM initiator RTT smoothing logic")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211219111352.e56cbf614a4d.Ib98004ccd2c7a55fd883a8ea7eebd810f406dec6@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
There's another set of error tables on newer (Bz) hardware,
support finding and dumping those error tables if present.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211210110539.c727a975b434.Ie5ad3fd974b700f1b90867b2b52ef7607799e8fe@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
