- 13 Sep, 2023 22 commits
-
-
Miri Korenblit authored
Currently we are setting the rate in the tx cmd for mgmt frames (e.g. during connection establishment). This was problematic when sending mgmt frames in eSR mode, as we don't know what link this frame will be sent on (This is decided by the FW), so we don't know what is the lowest rate. Fix this by not setting the rate in tx cmd and rely on FW to choose the right one. Set rate only for injected frames with fixed rate, or when no sta is given. Also set for important frames (EAPOL etc.) the High Priority flag. Fixes: 055b22e7 ("iwlwifi: mvm: Set Tx rate and flags when there is not station") Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230913145231.6c7e59620ee0.I6eaed3ccdd6dd62b9e664facc484081fc5275843@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Shaul Triebitz authored
If the channel bandwidth is greater or equal than 80MHz, enable FILS DF transmittion, even if the control channel is non-PSC. That's because that in 80MHz there must be a sub 20MHz PSC channel, and since the FILS DF is duplicated on all sub 20MHz channels, within the 80MHz (hence it will be sent on a PSC channel). Also, if FILS DF Tx is enabled, always configure the firmware with the actual channel bandwidth, even before there is a connected client (rather than the minimum bandwidth e.g. 20MHz), since FILS DF transmission on a PSC channel take presedent over power consumption. Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230913145231.83b9a76fc6c4.I6703111cc6befcd0e9cd9adf3cb127a648dbb7b1@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
If the device initialized with ME active, this would indeed work, since the NVM information would be obtained from ME. However, in the much more likely case that ME isn't active and the firmware takes actions requiring the sync, this was not working correctly when the firmware is only run at init to obtain NVM data, since mac80211 isn't even initialized. Fix this by moving the 'pldr_sync' handling to a different place. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230913145231.45a94d480e56.Id9277f1df6a63ab0dfca0d0c0f448c759e1b8e73@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Emmanuel Grumbach authored
When we drop frames we want to have something printed in the logger. This won't be printed by default of course. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230913145231.c2f02fecf66f.Ib472f9fd92856c6e5b5a99b68fdca0f694a531e9@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Gregory Greenman authored
Disable firmware debug asserts, which are used for internal firmware testing purposes only. Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230913145231.8feafd9b17be.Ia7bec82ac25897caab581692d67055aa1aca2ed2@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Miri Korenblit authored
This condition will never be true. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230913145231.56ff0569d16c.I455839fad0f4f05043815aee884fab9ec7323f7d@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Enable the TOP (HW part) fatal error interrupt and add a print when it happens. Currently FW always adds also the SW error interrupt, but for >= Bz we'll need to do PLDR in case this is asserted, so leave a TODO item already. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230913145231.127d914a4d0d.I41ea409df63474554ef727c49382d0b5bf15939e@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
If the hardware is not responding, as indicated by (currently) five consecutive HW errors during reading, then just give up and fail, rather than attempting forever and forever for this to not return any useful data anyway. Even though we no longer completely deadlock the machine if it takes a long time, we still make it pretty much unusable since we'll eventually hold the RTNL while waiting for this process to finish. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230913145231.345af79f431c.I5ecde6b76b1e3a1572bd59d3cf8f827e767cedeb@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
If the bus has no parent due to the topology, the device rescan (after some kind of reset was detected) wouldn't work. On the other hand, some platforms appear to require scanning the parent, though it's not clear why. However if there's no parent, then we skip the rescan, which isn't a good idea. Change the code to go to the parent only if that exists, and rescan the bus itself where it doesn't. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230913145231.f7795a1ccdab.I2b84810a743469a1bcabf3628262cf54311593f4@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Aditya Kumar Singh authored
cfg80211 has cfg80211_chandef_dfs_usable() function to know whether at least one channel in the chandef is in usable state or not. Also, cfg80211_chandef_dfs_cac_time() function is there which tells the CAC time required for the given chandef. Make these two functions visible to drivers by exporting their symbol to global list of kernel symbols. Lower level drivers can make use of these two functions to be aware if CAC is required on the given chandef and for how long. For example drivers which maintains the CAC state internally can make use of these. Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://lore.kernel.org/r/20230912051857.2284-2-quic_adisi@quicinc.comSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Abhishek Kumar authored
Currently the channel property updates are not propagated to driver. This causes issues in the discovery of hidden SSIDs and fails to connect to them. This change defines a new wiphy flag which when enabled by vendor driver, the reg_call_notifier callback will be trigger on beacon hints. This ensures that the channel property changes are visible to the vendor driver. The vendor changes the channels for active scans. This fixes the discovery issue of hidden SSID. Signed-off-by: Abhishek Kumar <kuabhs@chromium.org> Link: https://lore.kernel.org/r/20230629035254.1.I059fe585f9f9e896c2d51028ef804d197c8c009e@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Raj Kumar Bhagat authored
Currently regulatory update by driver is not allowed when the wiphy->regd is already set and drivers_request->intersect is false. During wiphy registration, some drivers (ath10k does this currently) first register the world regulatory to cfg80211 using wiphy_apply_custom_regulatory(). The driver then obtain the current operating country and tries to update the correct regulatory to cfg80211 using regulatory_hint(). But at this point, wiphy->regd is already set to world regulatory. Also, since this is the first request from driver after the world regulatory is set this will result in drivers_request->intersect set to false. In this condition the driver request regulatory is not allowed to update to cfg80211 in reg_set_rd_driver(). This restricts the device operation to the world regulatory. This driver request to update the regulatory with current operating country is valid and should be updated to cfg80211. Hence allow regulatory update by driver even if the wiphy->regd is already set and driver_request->intersect is false. Signed-off-by: Raj Kumar Bhagat <quic_rajkbhag@quicinc.com> Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://lore.kernel.org/r/20230421061312.13722-1-quic_rajkbhag@quicinc.comSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Aloka Dixit authored
Process FILS discovery and unsolicited broadcast probe response transmission configurations in ieee80211_change_beacon(). Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com> Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://lore.kernel.org/r/20230727174100.11721-6-quic_alokad@quicinc.comSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Aloka Dixit authored
FILS discovery and unsolicited broadcast probe response templates need to be updated along with beacon templates in some cases such as the channel switch operation. Add the missing implementation. Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com> Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://lore.kernel.org/r/20230727174100.11721-5-quic_alokad@quicinc.comSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Aloka Dixit authored
Modify the prototype for change_beacon() in struct cfg80211_op to accept cfg80211_ap_settings instead of cfg80211_beacon_data so that it can process data in addition to beacons. Modify the prototypes of ieee80211_change_beacon() and driver specific functions accordingly. Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com> Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://lore.kernel.org/r/20230727174100.11721-4-quic_alokad@quicinc.com [while at it, remove pointless "if (info)" check in tracing that just makes all the lines longer than they need be - it's never NULL] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Aloka Dixit authored
FILS discovery configuration gets updated only if the maximum interval is set to a non-zero value, hence there is no way to reset this value to 0 once set. Replace the check for interval with a new flag which is set only if the configuration should be updated. Add similar changes for the unsolicited broadcast probe response handling. Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com> Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://lore.kernel.org/r/20230727174100.11721-3-quic_alokad@quicinc.com [move NULL'ing to else branch to not have intermediate NULL visible] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Aloka Dixit authored
Add a new flag 'update' which is set to true during start_ap() if (and only if) one of the following two conditions are met: - Userspace passed an empty nested attribute which indicates that the feature should be disabled and templates deleted. - Userspace passed all the parameters for the nested attribute. Existing configuration will not be changed while the flag remains false. Add similar changes for unsolicited broadcast probe response transmission. Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com> Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://lore.kernel.org/r/20230727174100.11721-2-quic_alokad@quicinc.comSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Tom Rix authored
clang with W=1 reports net/wireless/lib80211_crypt_tkip.c:667:7: error: variable 'iv32' set but not used [-Werror,-Wunused-but-set-variable] u32 iv32 = tkey->tx_iv32; ^ This variable not used so remove it. Then remove a similar iv16 variable. Change the comment because the unmodified value is returned. Signed-off-by: Tom Rix <trix@redhat.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230517123310.873023-1-trix@redhat.com [change commit log wrt. 'length', add comment in the code] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
We really cannot even get into this as we can't have a BSS with a 5/10 MHz (scan) width, and therefore all the code handling shifted rates cannot happen. Remove it all, since it's broken anyway, at least with MLO. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
There really isn't any support for scanning at different channel widths than 20 MHz since there's no way to set it. Remove this support for now, if somebody wants to maintain this whole thing later we can revisit how it should work. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Dmitry Antipov authored
Since 'sprintf()' returns the number of characters emitted, an extra calls to 'strlen()' in 'ieee80211_bss()' may be dropped. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Link: https://lore.kernel.org/r/20230912035522.15947-1-dmantipov@yandex.ruSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Clearly, there's no space in the function name, not sure how that could've happened. Put the underscore that it should be. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Fixes: 56cfb8ce ("wifi: cfg80211: add flush functions for wiphy work") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 11 Sep, 2023 18 commits
-
-
Johannes Berg authored
EHT devices can support 512 MPDUs in an A-MPDU, each of which might be an A-MSDU and thus further contain multiple MSDUs, which need their own buffer each. Increase the number of buffers to avoid running out in high-throughput scenarios. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230830112059.824e522927f1.Ie5b4a2d3953072b9d76054ae67e2e45900d6bba4@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
On newer hardware, a queue's RB status / write pointer can be bigger than 4095 (0xFFF), so we cannot mask the value by 0xFFF unconditionally. Since anyway that's only necessary on older hardware, move the masking to the helper function and apply it only for older HW. This also moves the endian conversion in to handle it more easily. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230830112059.7be2a3fff6f4.I94f11dee314a4f7c1941d2d223936b1fa8aa9ee4@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Since 1024 isn't being tested right now, allow only 512 for now. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230830112059.6e80366716ad.I19022084ac978b9960b12b205c052a83ab141203@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Some cases of restart crashing here have been reported, while we figure out where this is going wrong, check the link more carefully to avoid the crash. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230830112059.2b81f52ce18e.I8f3b1962013107e2d7491d817c3349359341c6ee@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
The firmware was trying to report the B2 RU allocation in the place previously used here as well, but there's a HW block that clears the lower 8 bits in this metadata word even in sniffer mode. Thus, firmware moved B2 to another place, follow that. There's no need to detect the version since moving it to the other place if firmware didn't just means that we'll continue to report the (erroneous) zero value, and it's not really something we can detect from the firmware now. While debugging this we realized that the comments about placement in the metadata dwords are wrong, update them. Reported-by: Youhan Kim <youhank@qti.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230830112059.dec7f1e07ff8.I623fee2d710cc7b6f392d65b708883ed58632b45@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
The last member of the enum is meant to count the items, but sparse cannot increment the previous member due to its bitwise type. Declaring the last entry with a value doesn't work either (cannot mix bitwise/non-bitwise) and declaring it with a bitwise value doesn't work due to the way it gets used. This led to the current construct. However, that construct the kernel-doc script doesn't understand this construct due to the use of #ifdef/#else. Find another solution that makes both tools happy, we do now do declare it as the bitwise value but then just redefine it so that doesn't get used, all still under __CHECKER__ conditional. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230830112059.44bdf6a5fa9e.I9f1ea129f89e53043d48676aed0a3b8f6c31ac08@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Fix kernel-doc, adding various documentation, but in some cases (notably rate scaling) just removing the erroneous comment format. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230830112059.4ce1159b51ab.I2021ae335f6b8e50ee2c1c78a79c5eac1c1aa103@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Fix various missing kernel-doc annotations etc. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230830112059.a11b39f9a07e.Ia7b189f003db8f6ccaf0a547e71c80e00b85fb5a@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Mostly remove kernel-doc comment annotation since the comments really aren't kernel-doc, and fix a few other places. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230830112059.7178fb7c96fb.I6af1f291e306c50a3c4f5afcdc2ba0bbd4bea01f@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Fix the kernel-doc annotations here, adding the trans parameter and fixing the syntax. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230830112059.247919faf4fd.I489f8b3b2ebb49a421bd5d76ea0201262134fb67@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Miri Korenblit authored
Don't use variable err uninitialized. The reason for removing the check instead of initializing it in the beginning of the function is because that way static checkers will be able to catch issues if we do something wrong in the future. Fixes: bf976c81 ("wifi: iwlwifi: mvm: implement link change ops") Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230830112059.431b01bd8779.I31fc4ab35f551b85a10f974a6b18fc30191e9c35@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Fix kernel-doc issues. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230830112059.2edc4d82f717.Ic7c6f1153939903b067062c9aec8fb70e0a2c30d@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Emmanuel Grumbach authored
In case the user sets the enable_ini to some preset, we want to honor the value. Remove the ops to set the value of the module parameter is runtime, we don't want to allow to modify the value in runtime since we configure the firmware once at the beginning on its life. Fixes: b49c2b25 ("iwlwifi: Configure FW debug preset via module param.") Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230830112059.5734e0f374bb.I6698eda8ed2112378dd47ac5d62866ebe7a94f77@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
If there's an alternative link to use while the CSA is in progress, there's no need to disconnect since another link is still usable during the switching time. Change the code here to handle that accordingly. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230830112059.dd1b96a37e51.Idafdcbfcb36ca4c486f4221aef77643869331514@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
In the spec, CSA is defined roughly as follows: - TBTT x: beacon with CSA, count=n (old channel) - TBTT x+1: beacon with CSA, count=n-1 (old channel) - TBTT x+n-1: beacon with CSA, count=1 (old channel) "A Channel Switch Count field set to 1 indicates that the switch occurs immediately before the next TBTT. - TBTT x+n: beacon without CSA (new channel) When we detect it, we currently schedule the CSA event to be at 10 TUs before TBTT x+n-1, for a beacon interval, to give us quiet time. When this event *starts*, we currently notify mac80211 that the channel switch happened, which causes us to add a session protection event to listen for the first beacon (and enable TX etc. when that arrives). We don't even ask for a notification when this event ends so the code that handles that is effectively dead code. The session protection duration is 3 beacon intervals, scheduled at 10 TU before TBTT x+n-1. It will thus end just before TBTT x+n+2. Unfortunately, if the AP doesn't transmit or we miss just the first two beacons on the new channel, then this will cause us to disconnect. Or even just one, if the AP isn't quite aligned with the TBTT after the switch. However, listening to the _end_ of the time event isn't what we want either, because we want all the new PHY and other config that needs to come from mac80211 to start early, so we have a head-start for the new channel, since we're not going to use the old one anyway for this time. So since we don't really have anything better to do at this time, and this is relatively rare, just make the session protection use 5x the beacon interval instead of just 3x, so it's more likely we catch a beacon even if the AP neglected to send it, or we just miss it. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230830112059.a74176bac37c.I029a2ebcd1b5012327c728ffa1d33fac19cfdf4b@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Emmanuel Grumbach authored
Pass the right link_id to ieee80211_chswitch_done. Use the link_conf parameter passed to post_channel_switch() to get the right ap_sta_id. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230830112059.19470584fa51.Iad38b5369bededaa126b3eb3cff79f23d61bd783@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Use the correct link ID and per-link puncturing data instead of hardcoding link ID 0 and using deflink puncturing. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230827135854.0b6a211c8e75.I5724d32bb2dae440888efbc47334d8c115db9d50@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Ilan Peer authored
When user space transmits a management frame it is expected to use the MLD addresses if the connection is an MLD one. Thus, in case the management Tx is using the MLD address and no channel is configured off-channel should not be used (as one of the active links would be used). Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230827135854.73c8efce252f.Ie4b0a842debb24ef25c5e6cb2ad69b9f46bc4b2a@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-