When the firmware crashes, we first told the op_mode and only then,
changed the transport's state. This is a problem if the op_mode's
nic_error() handler needs to send a host command: it'll see that the
transport's state still reflects that the firmware is alive.
Today, this has no consequences since we set the STATUS_FW_ERROR bit and
that will prevent sending host commands. iwl_fw_dbg_stop_restart_recording
looks at this bit to know not to send a host command for example.
To fix the hibernation, we needed to reset the firmware without having
an error and checking STATUS_FW_ERROR to see whether the firmware is
alive will no longer hold, so this change is necessary as well.
Change the flow a bit.
Change trans->state before calling the op_mode's nic_error() method and
check trans->state instead of STATUS_FW_ERROR. This will keep the
current behavior of iwl_fw_dbg_stop_restart_recording upon firmware
error, and it'll allow us to call iwl_fw_dbg_stop_restart_recording
safely even if STATUS_FW_ERROR is clear, but yet, the firmware is not
alive.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240825191257.9d7427fbdfd7.Ia056ca57029a382c921d6f7b6a6b28fc480f2f22@changeid
[I missed this was a dependency for the hibernation fix, changed
the commit message a bit accordingly]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Check size of WGDS revision 3 is equal to 8 entries size with some header,
but doesn't depend on the number of used entries. Check that used entries
are between min and max but allow more to be present than are used to fix
operation with some BIOSes that have such data.
Fixes: 97f8a3d161 ("iwlwifi: ACPI: support revision 3 WGDS tables")
Signed-off-by: Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240825191257.cc71dfc67ec3.Ic27ee15ac6128b275c210b6de88f2145bd83ca7b@changeid
[edit commit message]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add support for activate/deactivate unii4 in USA, Canada and WW by
reading DSM function 8 from UEFI or ACPI and sending it to the FW.
Signed-off-by: Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240703125541.674604cbb6d1.Ibb946ae8ce7a760940a3c9d101e7f4f1808c43e4@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Fix all the prototype mismatch and "wrong kernel-doc identifier"
warnings, due to typos in or misformatting of the kernel-doc.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240625194805.6ec65cf9b88c.I7804114d7369f352e80a0e8430f7119af8e210de@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When UATS isn't enabled (no VLP/AFC AP support), we need to still
set the right bits in the channel/regulatory flags, so remove the
uats_enabled argument to the parsing etc.
Also, firmware deals just fine with getting the UATS table if it
supports the command even if the bits aren't set, so always send
it, since it's also needed if BIT(31) is set, but the driver need
not have any knowledge of that. Remove 'uats_enabled' entirely.
Fixes: 0d2fc8821a ("wifi: iwlwifi: nvm: parse the VLP/AFC bit from regulatory")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240618195731.a81e7234c4f6.Ic0131180d38e0f1ead2f7fa0e7583407ceaa0bd1@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This is the first step towards removing the P2P Device MAC.
Use ROC (which uses the AUX MAC) for P2P Device
discoveribility and action frames.
Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240605140556.8c90e457abbd.I8e340759ecb299e05b1809f3d8060429c6cbbd01@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This was needed when we had multiple types of transports. Now we only
have pcie, so there is no need for this ops.
Cleanup the code such as the different trans APIs will call the pcie
function directly, instead of calling the callback,
and remove struct iwl_trans_ops.
Signed-off-by: Yedidya Benshimol <yedidya.ben.shimol@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240605140327.8315ff64f9f3.Ifdbc1f26d49766f7de553dcb5f613885f4ee65cc@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add support for enable/disable 11be for china and South Korea by
reading DSM function 12 from UEFI or ACPI and sending it to the FW.
Signed-off-by: Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240512152312.037613d03c87.I4e5ee63c0dbdd4bd6c48daee7b0c88462b702423@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In practice, iwl_trans_get_rxq_dma_data() will not fail,
it only can do that if called with the wrong arguments.
But it does have an error value and doesn't initialize
the argument when it fails, so don't use the value then.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240512072733.faf3a1b87589.I77c950173cb914676fbd28483e5ef420bb9f1bc9@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add new time point to get the details of scan failure
While on it added other missing enum to match with FW.
Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com>
Reviewed-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240512072733.6781e76990c4.Iadfb3f6dd63a98fc35019772266b5ebddc5b5270@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
fw_running assumes that memory can be retrieved only after alive.
This assumption is no longer true as we support dump before alive.
To avoid invalid access to the NIC, check that STATUS_DEVICE_ENABLED
bit in trans status is set before dumping instead of the prior check.
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Reviewed-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240510170500.ca07138cedeb.I090e31d3eaeb4ba19f5f84aba997ccd36927e9ac@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In prph_mac_iter, ensure that all required addresses are dumped
even if a read fails. Currently, if a read fails, the region dump
is stopped, preventing the creation of prph_mac.lst.
By dumping all addresses even if a read fails, we can accurately
determine which addresses were successfully read and which were not.
Signed-off-by: Daniel Gabay <daniel.gabay@intel.com>
Reviewed-by: Eilon Rinat <eilon.rinat@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240506095953.31fa9ce91a1c.Ia0c86f70c7a6874c15ffc6f8235aa88530208546@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The firmware has different names for this, which is confusing
as even the convention of having the firmware name in a comment
after the struct definition wasn't met here. Fix the naming,
but keep UATS in some of it since that's the BIOS name.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240506095953.b0dfe17d5f44.I8f5f5a831c7b934ce3140f838315827c018103bb@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When requested, the firmware can return per-channel survey information
generally used for ACS (automatic channel selection). Add the API for
this, which consists of a flag and a new channel survey notification.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240506095953.1facde532676.I3864ac4bc0fecb7fd5136e85c07585ab7100234b@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Send AP_TX_POWER_CONSTRAINTS_CMD with no local maximum transmit
power constraint to FW and FW will update the TPE element with
required tx power limits.
Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240416134215.b6af4ecfcfe8.I07e8db349190e0c58c468c18477d8551288ac069@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add support for enable/disable 320 MHz for Japan and South Korea
by reading WBEM (WiFi Bandwidth Enablement per MCC) variable from
UEFI or ACPI and sending it to the FW.
Signed-off-by: Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240415114847.7946c3befbe1.I453c33f7ea48156ea2a3961f50a9003103fca5a5@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add support for enablement of PPAG for
- VLP for 6 GHz mode in CANADA, USA and ETSI countries.
- LPI for 6 GHz mode in CANADA.
- SP for 6 GHz mode in CANADA, USA and ETSI countries.
Signed-off-by: Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240415114847.e1893fe24ea3.Ic84cf576de0883c2184c939bdfad4b110a8a1815@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The first "new features" pull request for v6.10 with changes both in
stack and in drivers. The big thing in this pull request is that
wireless subsystem is now almost free of sparse warnings. There's only
one warning left in ath11k which was introduced in v6.9-rc1 and will
be fixed via the wireless tree.
Realtek drivers continue to improve, now we have support for RTL8922AE
and RTL8723CS devices. ath11k also has long waited support for P2P.
This time we have a small conflict in iwlwifi as we didn't consider it
as major enough to justify merging wireless tree to wireless-next. But
Stephen has an example merge resolution which should help with fixing
the conflict:
https://lore.kernel.org/all/20240326100945.765b8caf@canb.auug.org.au/
Major changes:
rtw89
* RTL8922AE Wi-Fi 7 PCI device support
rtw88
* RTL8723CS SDIO device support
iwlwifi
* don't support puncturing in 5 GHz
* support monitor mode on passive channels
* BZ-W device support
* P2P with HE/EHT support
ath11k
* P2P support for QCA6390, WCN6855 and QCA2066
-----BEGIN PGP SIGNATURE-----
iQFFBAABCgAvFiEEiBjanGPFTz4PRfLobhckVSbrbZsFAmYNIqIRHGt2YWxvQGtl
cm5lbC5vcmcACgkQbhckVSbrbZt8jAf9H+o91boD34/qVdI5LWEcFhVKEkHpNtwm
Y1sTKNBEtN1Gs2zcljjO6PqN9N4v2+lA42KSpzP5M42FfpI2aATI2v8jYsKTXOl2
YVwF+8pDiAsi0YtQTxIthygjzTpsePCfj8z0xJaKGm195T+fMm9UebYETrfxxOp/
z5StsJIPI0twgSLKKUWvLpX4ESt0l0HLJY1ok99sk4Cj36EKn6b9LbBinDKr6GcQ
mGNtPyq0j4l0kS5qae9BbXZUohO54o8wiFnApdwGfA7S/kLY7eUtwZy7T050b62P
zbNafwZbIjrH7dNcGfe6Fdr7PjQYFeI5Nh7dXxqM2LJOQsYXU/tcWQ==
=WrPE
-----END PGP SIGNATURE-----
Merge tag 'wireless-next-2024-04-03' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next
Kalle Valo says:
====================
wireless-next patches for v6.10
The first "new features" pull request for v6.10 with changes both in
stack and in drivers. The big thing in this pull request is that
wireless subsystem is now almost free of sparse warnings. There's only
one warning left in ath11k which was introduced in v6.9-rc1 and will
be fixed via the wireless tree.
Realtek drivers continue to improve, now we have support for RTL8922AE
and RTL8723CS devices. ath11k also has long waited support for P2P.
This time we have a small conflict in iwlwifi, Stephen has an example
merge resolution which should help with fixing the conflict:
https://lore.kernel.org/all/20240326100945.765b8caf@canb.auug.org.au/
Major changes:
rtw89
* RTL8922AE Wi-Fi 7 PCI device support
rtw88
* RTL8723CS SDIO device support
iwlwifi
* don't support puncturing in 5 GHz
* support monitor mode on passive channels
* BZ-W device support
* P2P with HE/EHT support
ath11k
* P2P support for QCA6390, WCN6855 and QCA2066
* tag 'wireless-next-2024-04-03' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (122 commits)
wifi: mt76: mt7915: workaround dubious x | !y warning
wifi: mwl8k: Avoid -Wflex-array-member-not-at-end warnings
wifi: ti: Avoid a hundred -Wflex-array-member-not-at-end warnings
wifi: iwlwifi: mvm: fix check in iwl_mvm_sta_fw_id_mask
net: rfkill: gpio: Convert to platform remove callback returning void
wifi: mac80211: use kvcalloc() for codel vars
wifi: iwlwifi: reconfigure TLC during HW restart
wifi: iwlwifi: mvm: don't change BA sessions during restart
wifi: iwlwifi: mvm: select STA mask only for active links
wifi: iwlwifi: mvm: set wider BW OFDMA ignore correctly
wifi: iwlwifi: Add support for LARI_CONFIG_CHANGE_CMD cmd v9
wifi: iwlwifi: mvm: Declare HE/EHT capabilities support for P2P interfaces
wifi: iwlwifi: mvm: Remove outdated comment
wifi: iwlwifi: add support for BZ_W
wifi: iwlwifi: Print a specific device name.
wifi: iwlwifi: remove wrong CRF_IDs
wifi: iwlwifi: remove devices that never came out
wifi: iwlwifi: mvm: mark EMLSR disabled in cleanup iterator
wifi: iwlwifi: mvm: fix active link counting during recovery
wifi: iwlwifi: mvm: assign link STA ID lookups during restart
...
====================
Link: https://lore.kernel.org/r/20240403093625.CF515C433C7@smtp.kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
There is a requirement from OEMs to support new bits in DSM function 7,
which will indicate enablement of 5.9 GHz in Canada.
Add support for this by reading those bits from BIOS and sending it to the
FW. mask unii4 allow bitmap based on LARI_CONFIG_CHANGE_CMD version
Signed-off-by: Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Reviewed-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240320232419.5c31ccd73119.I0363992efc3607368648d34a7918b2534150a3ca@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
iwl_fw_dbg_collect_sync() unconditionally accesses 'trig' at
the beginning of the function, even though the data has an
inner union and 'trig' isn't necessarily always used, it can
be 'desc' instead. Add comments clarifying why this is OK,
that 'trig'/'desc' must be first in the struct and how in it
the use of the union's sub-structs is differentiated.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240319100755.49c3a39737cc.I91c588e0d66b49f0ee9103e8d4a0e501c2fd36d6@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In version 4, in case of MLO GTK rekey during D3,
the firmware sends all the new keys, including
the keys on the non-active links.
Update also the non active link keys.
Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240311081938.6524de988ed3.Id065ddd2f4a71b0243c33ae0c5476ac41bfe2dc2@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Since the dump_data (struct iwl_fwrt_dump_data) is a union,
it's not safe to unconditionally access and use the 'trig'
member, it might be 'desc' instead. Access it only if it's
known to be 'trig' rather than 'desc', i.e. if ini-debug
is present.
Cc: stable@vger.kernel.org
Fixes: 0eb50c674a ("iwlwifi: yoyo: send hcmd to fw after dump collection completes.")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240319100755.e2976bc58b29.I72fbd6135b3623227de53d8a2bb82776066cb72b@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The version 6 command adds the puncture mask to the PHY
context and is otherwise the same. Support that in the
API definitions, but don't fill it yet.
While at it, also mark the field as removed from the link
context command since it moved from there to PHY context.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240218194912.2156fca5b1a5.I57f47f26ec0d96ecfb1192039f72b1c6d4e8a357@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Those devices' fifos are numbered differently.
Because of that, we were looking at the size of the VO fifo size to
determine the size of the A-MSDU which led to a lower throughput.
Note that for those devices the only user of the AC -> fifo mapping is
the size limitation of A-MSDU.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240218194912.da336ca2fa0a.I73e44d5fc474ebb6f275b9008950e59c012f33b2@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There's a conflict already and some upcoming changes
also depend on changes in wireless for being conflict-
free, so pull wireless in to make all that easier.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
