- 12 Feb, 2024 36 commits
-
-
Johannes Berg authored
The firmware will now start with 1500 byte A-MSDU size rather than 3500 as before, and that seems to cause some really hard to debug problems. Keep A-MSDU disabled if the size is less than 2000 to disable this for now. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240208185302.3dcd0a1767d0.I450d35f3085b3b04a96dd1e1e7d8c27bda9ce8f5@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Mukesh Sisodiya authored
6 GHz STA supports different power types as LPI, SP, VLP. and this information is provided by regulatory info. Add support in driver to parse the power type capability in regulatory info from FW and set it to the channel flags. Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240208185302.9c6a4acabdb3.I501de5c0d86b9702bf61158a2e91c954a1da9a2a@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Shaul Triebitz authored
In MFP, do not disconnect if an unprotected deauth or disassoc was received during D3. For that, need to configure wowlan with MFP (IS_11W_ASSOC). Now, in case of an unprotected deauth/disassoc, the wakeup reason returned by the firmware will be: IWL_WAKEUP_BY_11W_UNPROTECTED_DEAUTH_OR_DISASSOC (and not IWL_WOWLAN_WAKEUP_BY_DISCONNECTION_ON_DEAUTH which will cause a disconnection). Also, report this reason to cfg80211. In another patch, the driver will send an SA query. Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240206175739.fde438a22e3f.I3c8497520aaa95a22febff727b0ad08146965d47@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Shaul Triebitz authored
Add to cfg80211_wowlan_wakeup another wakeup reason - unprot_deauth_disassoc. To be set to true if the woke up was due to an unprotected deauth or disassoc frame in MFP. In that case report WOWLAN_TRIG_UNPROTECTED_DEAUTH_DISASSOC. Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240206164849.a3d739850d03.I8f52a21c4f36d1af1f8068bed79e2f9cbf8289ef@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Shaul Triebitz authored
Add a report reason for waking up due to an unprotected deauth/disassoc when MFP is used. If setting wowlan to wake on disconnection, and an unprotected deatuh/disassoc arrived (in MFP), some drivers might want to report wakeup due to unprotected deauth/disassoc, rather than dissassociation. Add support for that. Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240206164849.8dc9ad531a17.I7f8e926adf927f762e11aaa3458f6354665c7fc5@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
If the driver uses the new IEEE80211_CHAN_CAN_MONITOR, we may monitor on channels that are, e.g. via regulatory, otherwise considered disabled. However, we really shouldn't transmit on them, so prevent that. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240206164849.9c03dcf67dbe.Ib86a851c274c440908c663f6dd774b79bfc3965d@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
If the hardware supports a disabled channel, it may in some cases be possible to use monitor mode (without any transmit) on it when it's otherwise disabled. Add a new channel flag IEEE80211_CHAN_CAN_MONITOR that makes it possible for a driver to indicate such a thing. Make it per channel so drivers could have a choice with it, perhaps it's only possible on some channels, perhaps some channels are not supported at all, but still there and marked disabled. In _nl80211_parse_chandef() simplify the code and check only for an unknown channel, _cfg80211_chandef_usable() will later check for IEEE80211_CHAN_DISABLED anyway. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240206164849.87fad3a21a09.I9116b2fdc2e2c9fd59a9273a64db7fcb41fc0328@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
UHB stands for "Ultra High Band", but this term doesn't really exist in the spec. Rename all occurrences to "6 GHz", but keep a few defines for userspace API compatibility. Link: https://msgid.link/20240206164849.c9cfb9400839.I153db3b951934a1d84409c17fbe1f1d1782543fa@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Andrei Otcheretianski authored
This allows testing 160MHz channels with DFS concurrent. While at it, remove the TODO for adding a module param to enable NL80211_EXT_FEATURE_DFS_CONCURRENT. This is not really needed as mac80211_hwsim still needs to be loaded with custom regdom. Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240206164849.1b9955e511f0.I5e5315e3a047db3677bfb5ead003a3a4f7d29b13@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Aditya Kumar Singh authored
Currently, whenever AP link is brought down via ieee80211_stop_ap() function, all stations connected to the sdata are flushed. However, in case of MLO there is a requirement to flush only stations connected to that link and not all. For instance - Consider 2 GHz and 5 GHz are AP MLD. Now due to some reason 5 GHz link of this AP is going down (link removal or any other case). All stations connected, even legacy stations connected to 2 GHz link AP would also be flushed. Flushing of other link stations is not desirable. Fix this issue by passing self link ID to sta_flush() function. This would then only remove the stations which are still using the passed link ID as their link sta. Other stations will not be affected. Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Link: https://msgid.link/20240205162952.1697646-4-quic_adisi@quicinc.comSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Aditya Kumar Singh authored
Whenever sta_flush() function is invoked, all STAs present in that interface are flushed. In case of MLO, it is desirable to only flush such STAs that are at least using a given link id as one of their links. Add support for this by making change in the __sta_info_flush API argument to accept a link ID. And then, only if the STA is using the given link as one of its links, it would be flushed. Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Link: https://msgid.link/20240205162952.1697646-3-quic_adisi@quicinc.com [reword commit message, in particular this isn't about "active" links] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Aditya Kumar Singh authored
Currently whenever NL80211_CMD_DEL_STATION command is called without any MAC address, all stations present on that interface are flushed. However with MLO there is a need to flush such stations only which are using at least a particular link from the AP MLD interface. For example - 2 GHz and 5 GHz are part of an AP MLD. To this interface, following stations are connected - 1. One non-EHT STA on 2 GHz link. 2. One non-EHT STA on 5 GHz link. 3. One Multi-Link STA having 2 GHz and 5 GHz as active links. Now if currently, NL80211_CMD_DEL_STATION is issued by the 2 GHz link without any MAC address, it would flush all station entries. However, flushing of station entry #2 at least is not desireable since it is connected to 5 GHz link alone. Hence, add an option to pass link ID as well in the command so that if link ID is passed, stations using that passed link ID alone would be flushed and others will not. So after this, station entries #1 and #3 alone would be flushed and #2 will remain as it is. Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Link: https://msgid.link/20240205162952.1697646-2-quic_adisi@quicinc.com [clarify documentation] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Lorenzo Bianconi authored
Get rid of gfp parameter from ieee80211_obss_color_collision_notify since it is no longer used. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://msgid.link/f91e1c78896408ac556586ba8c99e4e389aeba02.1707389901.git.lorenzo@kernel.orgSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Ping-Ke Shih authored
Since WiFi 7 is expected to support MLO, so we should enable MAC-0/1 and PHY-0/1. By default, set dbcc_en=true, change quota to DBCC mode, and set MLO mode to 2 + 0 that means we only use 2x2 connection on MAC/PHY-0 for now. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240209065229.34515-12-pkshih@realtek.com
-
Po-Hao Huang authored
Reference the current quota mode to avoid misleading warnings. This patch is required after supporting DBCC quota mode. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240209065229.34515-11-pkshih@realtek.com
-
Chih-Kang Chang authored
Modify reg for BE generation when AP stop, otherwise have warning messages "Polling beacon packet empty fail". Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240209065229.34515-10-pkshih@realtek.com
-
Ping-Ke Shih authored
ctrl_nbtg_bt_tx is used to control AGC settings under non-shared path condition, which is affected by BT TX. To speed up IO, merge continual bit mask into one IO. Also, correct a register definition. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240209065229.34515-9-pkshih@realtek.com
-
Zong-Zhe Yang authored
When there are OBSS that cannot interpret 26-tone RU transmissions, we should disable 26-tone RU HE TB PPDU transmissions. So, add registers accordingly. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240209065229.34515-8-pkshih@realtek.com
-
Ping-Ke Shih authored
Hardware can use spatial reuse to reduce interference in OBSS environment, and originally use MAC header to match BSS color and AID. Change to use PLCP to match them earlier to prevent margin timing. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240209065229.34515-7-pkshih@realtek.com
-
Ping-Ke Shih authored
When going to use PHY-1, reset the hardware to make it work properly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240209065229.34515-6-pkshih@realtek.com
-
Ping-Ke Shih authored
Consider mac_idx as an argument to set this register to disable QoS NULL update MUEDCA timer. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240209065229.34515-5-pkshih@realtek.com
-
Ping-Ke Shih authored
DLE (data link engine) could hold quota when we are going to enable/disable MAC-1 block, so trigger hardware to return all held quota. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240209065229.34515-4-pkshih@realtek.com
-
Ping-Ke Shih authored
We are going to support MLO/DBCC, so need to load parameter table to PHY-1 as well. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240209065229.34515-3-pkshih@realtek.com
-
Ping-Ke Shih authored
PHY-1 can be seen as a copy of PHY-0, and the difference is their base register address, so add a function to get offset to access PHY-1. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240209065229.34515-2-pkshih@realtek.com
-
Alexey Berezhok authored
In 'brcmf_cfg80211_start_ap()', not assume that NL80211_HIDDEN_SSID_NOT_IN_USE is zero but prefer an explicit check instead. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Alexey Berezhok <a@bayrepo.ru> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240208085121.2430-1-a@bayrepo.ru
-
Kees Cook authored
wifi: mwifiex: Refactor 1-element array into flexible array in struct mwifiex_ie_types_chan_list_param_set struct mwifiex_ie_types_chan_list_param_set::chan_scan_param is treated as a flexible array, so convert it into one so that it doesn't trip the array bounds sanitizer[1]. Only a few places were using sizeof() on the whole struct, so adjust those to follow the calculation pattern to avoid including the trailing single element. Examining binary output differences doesn't appear to show any literal size values changing, though it is obfuscated a bit by the compiler adjusting register usage and stack spill slots, etc. Link: https://github.com/KSPP/linux/issues/51 [1] Cc: Brian Norris <briannorris@chromium.org> Cc: Kalle Valo <kvalo@kernel.org> Cc: Dmitry Antipov <dmantipov@yandex.ru> Cc: Johannes Berg <johannes.berg@intel.com> Cc: zuoqilin <zuoqilin@yulong.com> Cc: Ruan Jinjie <ruanjinjie@huawei.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Cc: Gustavo A. R. Silva <gustavoars@kernel.org> Cc: linux-wireless@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240207103024.make.423-kees@kernel.org
-
David Mosberger-Tang authored
Document ATWILC1000/ATWILC3000 Baremetal Wi-Fi/BLE Link Controller Software Design Guide https://tinyurl.com/yer2xhyc says that bit 0 of the CRC7 code must always be a 1. I confirmed that today with a logic analyzer: setting bit 0 causes wilc1000 to accept a command with CRC7 enabled, whereas clearing bit 0 causes wilc1000 to reject the command with a CRC error. Signed-off-by: David Mosberger-Tang <davidm@egauge.net> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240207050736.2717641-1-davidm@egauge.net
-
Zong-Zhe Yang authored
During mac80211 reconfig, chanctx ops of multiple channels might not be called in order as normal cases. However, we expect the first active chanctx always to be put at our sub entity index 0. So, if it does not, we do a swap there. Besides, reconfig won't allocate a new chanctx object. So, we should reset the reference count when ops add chanctx. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240206030624.23382-7-pkshih@realtek.com
-
Zong-Zhe Yang authored
After MLO, we will need to consider not only active chanctx but also active interfaces (roles) to decide entity things. So in advance, we move handling from chanctx_ops::add/remove to chanctx_ops::assign_vif/unassign_vif. Then, we can recalculate and aware active interfaces' changes. For now, behavior should not be really different, since active chanctx and active interface are one-to-one mapping before MLO. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240206030624.23382-6-pkshih@realtek.com
-
Zong-Zhe Yang authored
Originally, we consider weight only based on how many chanctxs that mac80211 sets. However, we need to consider both active chanctxs and active interfaces to distinguish MCC (multiple channel concurrent) from impending MLO. Although the logic of handling is extended, for now, behavior might not be different under current condition. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240206030624.23382-5-pkshih@realtek.com
-
Zong-Zhe Yang authored
Originally, we just declared two sub-entity, and according to rolling down mechanism, we ensured that index 0 contained sub-entity as long as there are sub-entity. So, we could use for-loop after deciding the last index. But, we are preparing to expand num of sub-entity for MLO. Then, there won't be just two sub-entity. And, there might be holes between two bits in the bitmap. So, we cannot simply do for-loop as before. Instead, we need to follow the set bits. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240206030624.23382-4-pkshih@realtek.com
-
Zong-Zhe Yang authored
Originally, we replaced sub-entity of index 0 with another one in some cases. However, we will need a swap here in following implementations. So, we introduce it ahead and change code from replacing to swapping. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240206030624.23382-3-pkshih@realtek.com
-
Zong-Zhe Yang authored
Some of our calculation during concurrent mode depend on last beacon TSF. Originally, we just set IEEE80211_HW_TIMING_BEACON_ONLY and get what we want from mac80211. But, IEEE80211_HW_TIMING_BEACON_ONLY will be restricted once we declare MLO. Since we are about to consider the MLO stuffs, so sync beacon TSF by ourselves now and unset IEEE80211_HW_TIMING_BEACON_ONLY. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240206030624.23382-2-pkshih@realtek.com
-
Ajay Singh authored
WILC driver currently applies some default configuration whenever the firmware is initialized, and sets the default preamble size to short. However, despite this passed option, firmware is also able to successfully connect to access points only using long preamble, so this setting does not really enforce short preambles and is misleading regarding applied configuration. Update default configuration and make it match the firmware behavior by passing the existing WILC_FW_PREAMBLE_AUTO value (2 instead of 0). The updated setting does not really alter firmware behavior since it is still capable to connect to both short preamble and long preamble access points, but at list the setting now expresses for real the corresponding firmware behavior. More info: it has been implemented to address the transmission (Tx) blackout issue observed in the 802.11b mode. The modification has no impact on the other modes, which will continue to work as they did in the previous implementation. This change will allow the 802.11b transmission (2, 5.5, 11Mbps) to use long preamble. Signed-off-by: Ajay Singh <ajay.kathat@microchip.com> Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240115-wilc_1000_fixes-v1-1-54d29463a738@bootlin.com
-
Dmitry Antipov authored
Use convenient 'kstrtou32_from_user()' in 'mwifiex_verext_write()' and 'kstrtobool_from_user()' in 'mwifiex_timeshare_coex_write()', respectively. Compile tested only. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240110115314.421298-1-dmantipov@yandex.ru
-
Arnd Bergmann authored
The #ifdef check around the function definition for two functions was changed without also changing the one on the declaration: drivers/net/wireless/intel/iwlwifi/fw/uefi.c:359:6: error: redefinition of 'iwl_uefi_get_sgom_table' 359 | void iwl_uefi_get_sgom_table(struct iwl_trans *trans, | ^~~~~~~~~~~~~~~~~~~~~~~ In file included from drivers/net/wireless/intel/iwlwifi/fw/uefi.c:11: drivers/net/wireless/intel/iwlwifi/fw/uefi.h:294:6: note: previous definition of 'iwl_uefi_get_sgom_table' with type 'void(struct iwl_trans *, struct iwl_fw_runtime *)' 294 | void iwl_uefi_get_sgom_table(struct iwl_trans *trans, struct iwl_fw_runtime *fwrt) | ^~~~~~~~~~~~~~~~~~~~~~~ drivers/net/wireless/intel/iwlwifi/fw/uefi.c:392:5: error: redefinition of 'iwl_uefi_get_uats_table' 392 | int iwl_uefi_get_uats_table(struct iwl_trans *trans, | ^~~~~~~~~~~~~~~~~~~~~~~ drivers/net/wireless/intel/iwlwifi/fw/uefi.h:299:5: note: previous definition of 'iwl_uefi_get_uats_table' with type 'int(struct iwl_trans *, struct iwl_fw_runtime *)' 299 | int iwl_uefi_get_uats_table(struct iwl_trans *trans, | ^~~~~~~~~~~~~~~~~~~~~~~ Adapt it by merging the declarations into the existing #ifdef block. Fixes: 74f4cd71 ("wifi: iwlwifi: take SGOM and UATS code out of ACPI ifdef") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://msgid.link/20240212112343.1148931-1-arnd@kernel.orgSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 09 Feb, 2024 1 commit
-
-
Johannes Berg authored
This was still referring to cfg80211_chandef_primary_freq(), fix it. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Fixes: b82730bf ("wifi: cfg80211/mac80211: move puncturing into chandef") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 08 Feb, 2024 3 commits
-
-
Johannes Berg authored
We've seen this warning trigger, and while the reason is probably obvious, I haven't been able to see it yet. Add more information to the warning message to help identify the cause. Also print out both index and SSN for all the messages. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240206175739.581427dc81fc.I9a109d02b4349807dce521c693ecd3516ec58cc0@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
This is always a bit confusing, the code first does all the reclaim (with its own debug messages), and _then_ prints it got a BA notification from firmware. Turn that around. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240206175739.825245e0803f.Ic607c57f43eb7c7ff122ffee8f3994fd040d578f@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
If this warning triggers we don't really know why, print out the return value so we can see it. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240206175739.b1b907741e85.Ib8ee9c90bd8f1af69969981ff0c63e9cc3123e1f@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-