- 26 Jun, 2024 34 commits
-
-
Miri Korenblit authored
This is no longer used Signed-off-by:
Miri Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://patch.msgid.link/20240625194805.17a1484f2485.I095c7482ac517111081f8ff40312b48ffdd7ff94@changeidSigned-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Emmanuel Grumbach authored
We don't use the new field, but at least, document the change. Signed-off-by:
-
Johannes Berg authored
Since we always block EMLSR for ROC, we also need to always unblock it, even if we don't have a P2P device interface. Fix this. Fixes: a1efeb82 ("wifi: iwlwifi: mvm: Block EMLSR when a p2p/softAP vif is active") Signed-off-by:
-
Johannes Berg authored
The lookup function iwl_mvm_rcu_fw_link_id_to_link_conf() is normally called with input from the firmware, so it should use IWL_FW_CHECK() instead of WARN_ON(). Signed-off-by:
-
Johannes Berg authored
If the firmware has MLD APIs, it will handle all timing and we don't need to give it timestamps. Therefore, we don't care about the timestamps stored in the BSS table, so there's no need to flush the BSS table. Signed-off-by:
-
Daniel Gabay authored
These are not MVM specific. Signed-off-by:
Daniel Gabay <daniel.gabay@intel.com> Signed-off-by:
-
Golan Ben Ami authored
LNL is the codename for the upcoming Series 2 Core Ultra processors designed by Intel. AX101, AX201 and AX203 devices are not shiped on LNL platforms, so don't support them. Signed-off-by:
Golan Ben Ami <golan.ben.ami@intel.com> Signed-off-by:
-
Johannes Berg authored
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: 0d2fc882 ("wifi: iwlwifi: nvm: parse the VLP/AFC bit from regulatory") Signed-off-by:
-
Johannes Berg authored
If channels are marked VLP, then we're actually also allowed to be VLP AP/GO. Enable this. Signed-off-by:
-
Johannes Berg authored
This isn't related to whether or not "fw can be loaded", but rather requesting that ME go into a state where doing a product reset is safe. This is related to FW load only in the specific case of where it's used today in iwlmvm, notably when it's known that the firmware itself will (or at least may) do a product reset during load. Clarify the documentation. I was tempted to rename things too, but on the ME side it really is also called PLDR (which is a Windows term and may not even match the complete behaviour since doing a full product reset from the driver also requires calling an ACPI method first.) So keep the name aligned with ME. Signed-off-by:
-
Johannes Berg authored
PLDR (product level device reset) is a Windows term, and is something the driver triggers there, AFAICT. Really what 'pldr_sync' here wants to capture is whether or not the firmware will/may do a product reset during initialization, which makes the device drop off the bus, requiring a rescan. If this is the case, obviously the init will fail/time out, so we don't want to report all kinds of errors etc., hence this tracking variable. Rename it to 'fw_product_reset' to capture the meaning better. Signed-off-by:
-
Ilan Peer authored
When setting the keys for secure measurement with an AP the station is associated with, the TK should only be referenced and not copied. In addition set the cipher only when the correct station is found. Fixes: 626be4bf ("wifi: iwlwifi: mvm: modify iwl_mvm_ftm_set_secured_ranging() parameters") Signed-off-by:
Ilan Peer <ilan.peer@intel.com> Signed-off-by:
-
Johannes Berg authored
Since the function isn't actually common (any more), just dissolve it. Signed-off-by:
-
Emmanuel Grumbach authored
Those bits are never used. Signed-off-by:
-
Emmanuel Grumbach authored
The new op_mode won't have this callback. Signed-off-by:
-
Miri Korenblit authored
Start supporting API version 92 for new devices. Signed-off-by:
-
Miri Korenblit authored
iwl_trans_pcie_gen2_fw_alive doesn't use the scd_addr parameter, it was there only because we needed the functio to have a prototype same as iwl_trans_ops::fw_alive callback. But now the ops is removed so no reason to keep the parameter. Signed-off-by:
-
Miri Korenblit authored
This debug is not in use anymore. Remove it. Signed-off-by:
-
Emmanuel Grumbach authored
This will allow to suspend / resume the system without resetting the firmware. This will allow to reduce the resume time. In case the fast_resume fails, stop the device and bring it up from scratch. Raise the timeout for the D3_END notification since in some iterations, it took 240ms. Signed-off-by:
-
Daniel Gabay authored
Fix incorrect use of _tx_ valid ant data in the function. Fixes: 4ea1ed1d ("wifi: iwlwifi: mvm: support set_antenna()") Signed-off-by:
-
Johannes Berg authored
AP interfaces fundamentally cannot leave the channel, so multi- channel operation with them isn't really possible. We shouldn't advertise support for such, at least not as long as we don't have full multi-radio support. Thus, remove the AP bit from the interface combinations for two channels and add another set for just one channel that has it. Also, to avoid duplicating everything even more, unify the NAN and non-NAN cases. Signed-off-by:
-
Emmanuel Grumbach authored
Do not access legacy bits for new devices, this has no effect. Somehow, wowlan worked despite the usage of the wrong bits. Now that we want to keep the firmware loaded during suspend even without wowlan, this change is needed. Signed-off-by:
-
Emmanuel Grumbach authored
This will allow the low level driver to take different actions for different flows. Signed-off-by:
-
Ilan Peer authored
Call the tracing function even if the cfg80211 callbacks are not set. This would allow better understanding of user space actions. Reviewed-by:
-
Johannes Berg authored
Check that the SSID in beacons is correct, if it's not hidden and beacon protection is enabled (otherwise there's no value). If it doesn't match, disconnect. Reviewed-by:
-
Johannes Berg authored
When updating a channel context, the code can apply wider bandwidth TDLS STA channel definitions to each and every channel context used by the device, an approach that will surely lead to problems if there is ever more than one. Restrict the wider BW TDLS STA consideration to only TDLS STAs that are actually related to links using the channel context being updated. Fixes: 0fabfaaf ("mac80211: upgrade BW of TDLS peers when possible") Reviewed-by:
-
Johannes Berg authored
We've open-coded this twice and will need it again, add ieee80211_tdls_sta_link_id() to get the one link ID for a TDLS STA. Reviewed-by:
-
Johannes Berg authored
In channel switch without an additional channel context, where the reassign logic kicks in, we also need to update the station bandwidth and chandef minimum width correctly to avoid having station rate control configured to wider bandwidth than the channel context. Do that now. Reviewed-by:
-
Johannes Berg authored
Make ieee80211_chan_bw_change() able to use the reserved chanreq (really the chandef part of it) for the calculations, so it can be used _without_ applying the changes first. Remove the comment that indicates this is required, since it no longer is. However, this capability only gets used later. Also, this is not ideal, we really should not different so much between reserved and non-reserved usage, to simplify. That's a further cleanup later though. Reviewed-by:
-
Johannes Berg authored
We'll need this as well for channel switching cases, so add the ability now to pass the chandef to calculate for. Reviewed-by:
-
Johannes Berg authored
We'll need this function to take a new chandef in (some) channel switching cases, so prepare for that by allowing that to be passed and using it if so. Clean up the code a little bit while at it. Reviewed-by:
-
Johannes Berg authored
The code currently handles ECSA (extended channel switch announcement) public action frames. Handle also their protected dual, which actually is protected. Reviewed-by:
-
Johannes Berg authored
Public action extended channel switch announcement (ECSA) frames cannot be protected well, the spec is unclear about what should happen in the presence of stations that can receive protected dual and stations that cannot. Mitigate these issues by not treating public action frames as the absolute truth, only treat them as a hint to stop transmitting (quiet mode), and do the remainder of the CSA handling only when receiving the next beacon (or protected action frame) that contains the CSA; or, if it doesn't, simply stop being quiet and continue operating normally. This limits the exposure to malicious ECSA public action frames, since they cannot cause a disconnect now, only a short interruption in traffic. Reviewed-by:
-
Johannes Berg authored
This code is duplicated many times, refactor it into new separate functions. Reviewed-by:
-
- 18 Jun, 2024 6 commits
-
-
Alexis Lothoré authored
Issuing a system suspend command raises the following warning: WARNING: CPU: 0 PID: 15 at drivers/mmc/core/sdio.c:1042 mmc_sdio_suspend+0xd4/0x19c CPU: 0 PID: 15 Comm: kworker/u2:1 Not tainted 6.7.0-rc1-wt+ #710 Hardware name: Atmel SAMA5 Workqueue: events_unbound async_run_entry_fn unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x48 dump_stack_lvl from __warn+0x98/0x160 __warn from warn_slowpath_fmt+0xcc/0x140 warn_slowpath_fmt from mmc_sdio_suspend+0xd4/0x19c mmc_sdio_suspend from mmc_bus_suspend+0x50/0x70 mmc_bus_suspend from dpm_run_callback+0xe4/0x248 dpm_run_callback from __device_suspend+0x234/0x91c __device_suspend from async_suspend+0x24/0x9c async_suspend from async_run_entry_fn+0x6c/0x210 async_run_entry_fn from process_one_work+0x3a0/0x870 [...] This warning is due to a check in SDIO core ensuring that interrupts do not remain enabled for cards being powered down during suspend. WILC driver currently does not set the MMC_PM_KEEP_POWER flag, so disable interrupt when entering resume. Signed-off-by:
Alexis Lothoré <alexis.lothore@bootlin.com> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240613-wilc_suspend-v1-6-c2f766d0988c@bootlin.com
-
Alexis Lothoré authored
WILC1000 suspend/resume implementation is currently composed of two parts: suspend/resume ops implemented in cfg80211 ops, which merely sets a flag, and suspend/resume ops in sdio/spi driver which, based on this flag, execute or not the suspend/resume mechanism. This dual set of ops is not really needed , so keep only the sdio part to implement suspend/resume. While doing so, remove the now unused suspend_event flag. Signed-off-by:
-
Alexis Lothoré authored
Just move the suspend method next to the resume method in the sdio part Signed-off-by:
-
Alexis Lothoré authored
There is no reason to keep the MMC host claimed during suspend. Signed-off-by:
-
Alexis Lothoré authored
host_wakeup_notify and host_sleep_notify are surrounded by chip_wakeup and chip_allow_sleep calls, which theorically need to be protected with the hif_cs lock. This lock protection is currently missing. Instead of adding the lock where those two functions are called, move those in host->chip suspend notifications to benefit from the lock already used there (in bus_acquire/bus_release) Signed-off-by:
-
Ajay Singh authored
Driver systematically disables some power mechanism each time it starts the chip firmware (so mostly when interface is brought up). This has a negative impact on some specific scenarios when the chip is exposed as a hotpluggable SDIO card (eg: WILC1000 SD): - when executing suspend/resume sequence while interface has been brought up - rebooting the platform while module is plugged and interface has been brought up Those scenarios lead to mmc core trying to initialize again the chip which is now unresponsive (because of the power sequencer setting), so it fails in mmc_rescan->mmc_attach_sdio and enter a failure loop while trying to send CMD5: mmc0: error -110 whilst initialising SDIO card mmc0: error -110 whilst initialising SDIO card mmc0: error -110 whilst initialising SDIO card [...] Preventing the driver from disabling this "power sequencer" fixes those enumeration issues without affecting nominal operations. Signed-off-by:
Ajay Singh <ajay.kathat@microchip.com> Signed-off-by:
-
