- 26 Jun, 2024 24 commits
-
-
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:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20240618194245.ccf849642af8.I01dded6b2393771b7baf8b4b17336784d987c7c2@changeidSigned-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 <emmanuel.grumbach@intel.com> 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:
Daniel Gabay <daniel.gabay@intel.com> Reviewed-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 14 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:
-
Russell King (Oracle) authored
wlcore firmware versions are structured thusly: chip.if-type.major.sub-type.minor e.g. 8 9 0 0 58 With WL18xx ignoring the major firmware version, looking for a firmware version that conforms to: chip >= 8 if-type >= 9 major (don't care) sub-type (don't care) minor >= 58 Each test is satisfied if the value read from the firmware is greater than the minimum, but if it is equal (or we don't care about the field), then the next field is checked. Thus it doesn't recognise 8.9.1.x.0 as being newer than 8.9.0.x.58 since the major and sub-type numbers are "don't care" and the minor needs to be greater or equal to 58. We need to change the major version from "ignore" to "0" for this later firmware to be correctly detected, and allow the dual-firmware version support to work. Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Russell King (Oracle) authored
Add the necessary code to read the 8.9.1 firmware status into the driver private status structure, augmenting the 8.9.0 firmware status code. New structure layout taken from: https://git.ti.com/cgit/wilink8-wlan/build-utilites/tree/patches/kernel_patches/4.19.38/0023-wlcore-Fixing-PN-drift-on-encrypted-link-after-recov.patch?h=r8.9&id=a2ee50aa5190ed3b334373d6cd09b1bff56ffcf7Signed-off-by:
-
Russell King (Oracle) authored
TI Wl18xx firmware adds a "pn16" field for AES and TKIP keys as per their patch: https://git.ti.com/cgit/wilink8-wlan/build-utilites/tree/patches/kernel_patches/4.19.38/0023-wlcore-Fixing-PN-drift-on-encrypted-link-after-recov.patch?h=r8.9&id=a2ee50aa5190ed3b334373d6cd09b1bff56ffcf7 Add support for this, but rather than requiring the field to be present (which would break existing firmwares), make it optional. Signed-off-by:
-
Russell King (Oracle) authored
Updates for WL18xx firmware 8.9.1.x.x need to know the AP encryption key type. Store this when a new key is set. Patch extracted from: https://git.ti.com/cgit/wilink8-wlan/build-utilites/tree/patches/kernel_patches/4.19.38/0023-wlcore-Fixing-PN-drift-on-encrypted-link-after-recov.patch?h=r8.9&id=a2ee50aa5190ed3b334373d6cd09b1bff56ffcf7Signed-off-by:
-
Russell King (Oracle) authored
wlcore_fw_status() is passed a pointer to the struct wl_fw_status to decode the status into, which is always wl->fw_status. Rather than referencing wl->fw_status within wlcore_fw_status(), use the supplied argument so that we access this member in a consistent manner. Signed-off-by:
-
Russell King (Oracle) authored
Referring to status->counters.tx_lnk_free_pkts[i] multiple times leads to less efficient code. Cache this value in a local variable. This also makes the code clearer. Signed-off-by:
-
Russell King (Oracle) authored
wl18xx_tx_immediate_complete() iterates through the completed transmit descriptors in a circular fashion, and in doing so uses a modulus operation that is not a power of two. This leads to inefficient code generation, which can be easily solved by providing a helper to increment to the next descriptor. Use this more efficient solution. Signed-off-by:
-
Russell King (Oracle) authored
Fix the calculation of clear_offset, which may overflow the end of the buffer. However, this is harmless if it does because in that case it will be recalculated when we copy the chunk of messages at the start of the buffer. Signed-off-by:
-
- 12 Jun, 2024 2 commits
-
-
Wolfram Sang authored
There is a confusing pattern in the kernel to use a variable named 'timeout' to store the result of wait_for_completion_timeout() causing patterns like: timeout = wait_for_completion_timeout(...) if (!timeout) return -ETIMEDOUT; with all kinds of permutations. Use 'time_left' as a variable to make the code self explaining. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by:
-
Wolfram Sang authored
There is a confusing pattern in the kernel to use a variable named 'timeout' to store the result of wait_for_completion_interruptible_timeout() causing patterns like: timeout = wait_for_completion_interruptible_timeout(...) if (!timeout) return -ETIMEDOUT; with all kinds of permutations. Use 'time_left' as a variable to make the code self explaining. Fix to the proper variable type 'long' while here. Signed-off-by:
-
