This is set when a P2P ROC ends, and uses as an indication inside
iwl_mvm_roc_done_wk that the resources used for this ROC (sta/link)
needs to be flushed/deactivated (respectively).
But we also have IWL_MVM_STATUS_ROC_RUNNING, which is set whenever
P2P ROC starts, and is not even used in iwl_mvm_roc_done_wk.
Use IWL_MVM_STATUS_ROC_RUNNING as an indicator, and remove the redundant
bit.
While at it, add a call to synchronize_net also for the
AUX ROC case, which is missing in the existing code.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240205211151.0494f75de311.Ic4aacacf7581a5c9046c4f1df87cbb67470853e7@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The fw_trips_index[] array in struct iwl_mvm_thermal_device is only
populated, but never read, so drop it.
Note that the iwl_mvm_send_temp_report_ths_cmd() code populating
fw_trips_index[] is questionable, because it accesses a trips table
of a thermal zone directly, which is not guaranteed to work in the
future.
No functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Miri Korenblit <Miriam.rachel.korenblit@intel.com>
The wiphy_work infra ensures that the entire worker will run
with the wiphy mutex. It is useful to have RX handlers
running as a wiphy_work, when we don't want the handler to
run in parallel with mac80211 work (to avoid races).
For example - BT notification can disable eSR starting from the next
patch.
In ieee80211_set_active_links we first check that eSR is
allowed, (drv_can_activate_links) and then activate it.
If the BT notif was received after drv_can_activate_links
(which returned true), and before the activation - eSR will be
activated when it shouldn't.
If BT notif is handled with the wiphy mutex, it can't run in
parallel to ieee80211_set_active_links, which also holds that
mutex.
Add the necessary infrastructure here, for use in the next commit.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://msgid.link/20240123200528.ce83d16cdec8.I35ef53fa23f58b9ec17924099238b61deafcecd7@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In order to get regulatory domain, driver sends MCC_UPDATE_CMD to the
FW. One of the parameters in the response is the status which can tell
if the regdomain has changed or not.
When iwl_mvm_init_mcc() is called during iwl_op_mode_mvm_start(), then
sband is still NULL and channel parameters (i.e. chan->flags) cannot be
initialized. When, further in the flow, iwl_mvm_update_mcc() is called
during iwl_mvm_up(), it first checks if the regdomain has changed and
then skips the update if it remains the same. But, since channel
parameters weren't initialized yet, the update should be forced in this
codepath. Fix that by adding a corresponding parameter to
iwl_mvm_init_fw_regd().
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20231017115047.78b2c5b891b0.Iac49d52e0bfc0317372015607c63ea9276bbb188@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The firmware / hardware of devices supporting RSS is able to report
duplicates and packets that time out inside the reoder buffer. We can
now remove all the complex logic that was implemented to keep all the Rx
queues more the less synchronized: we used to send a message to all the
queues through the firmware to teach the different queues about what is
the current SSN every 2048 packets.
Now that we rely on the firmware / hardware to detect duplicates, we can
completely remove the code that did that in the driver and it has been
reported that this code was spuriously dropping legit packets.
Suggested-by: Sultan Alsawaf <sultan@kerneltoast.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20231017115047.54cf4d3d5956.Ic06a08c9fb1e1ec315a4b49d632b78b8474dab79@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
As session protection API is moving to be per link instead of per mac,
move the time events to be per link too.
Since there is only one concurrent time event per mac, it feels
unnecessary to have the time_event as a member of iwl_mvm_link_info.
(That way we will have to iterate over all links each time we want to
clear a time event, and also we will need mac80211 to tell us the link
id when mgd_tx_complete() is called.)
So leave this as a member of iwl_mvm_vif, but add the link id to the
time_event structure.
The link id in time_event will only be maintained and used for:
1. When SESSION_PROTECTION_CMD is supported (before it, we don't have MLO)
2. For time_events of types SESSION_PROTECT_CONF_ASSOC,
SESSION_PROTECT_CONF_P2P_DEVICE_DISCOV, and
SESSION_PROTECT_CONF_P2P_GO_NEGOTIATION
(not for aux roc/ Hot Spot time_events).
For P2P, non-MLO connections, and pre-MLD API, deflink id, meaning 0,
will be used
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/20231017115047.21496bcacb18.I79d037325b4fae4c12a22d9477e53fc9c537ad46@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
bss_info_changed() callback of mac80211 was originally in both
MLD and non-MLD API. Therefore, we extracted the common part
to a function which receives a callback structure with the
mode-specific (non-MLO\MLO) ops. Eventually, for MLO API,
bss_info_changed() callback was split into 2 callbacks:
link_info_changed() and vif_cfg_changed() so it is no longer in use
for MLO, only for non-MLO.
Remove the code that uses the mode-specific callback structure.
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/20231011130030.b65fbcdb9295.I2a64a6f1178ee0466755d728addc77acbb2ed6f4@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add simple logic that would allow using EMLSR in case
there are multiple valid links:
- In case the connection establishment has just been
completed try to find a valid link pair for EMLSR
functionality where one of the links in the pair is
the current active link.
- In case the valid links changed after connection
was already established, try to find a valid link pair
for EMLSR functionality, in case the EMSLR is not active
yet.
If a valid link pair is found call mac80211 to asynchronously
set the new link pair, otherwise continue using the current active
links.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20231004123422.0c7b89ab29c2.I6600bd16551d75e2bf520d8d0add525568a9f85f@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add a per-link debugfs entry in iwlmvm level so we can read/write link
related parameters.
Do it by implementing the link_add_debugfs API introduced by mac80211.
Each entry will have a path like this:
.../netdev:wlan0/link-X/iwlmvm/<file_name>
for each link X.
For non-MLD vifs this callback is called when the original vif
debugfs dir is also created, so handle that case by not creating
the 'iwlmvm' directory again.
Note that we don't have to worry about the cleaning the iwlmvm/*
directory as it is already done by mac80211 when removing the link
(or netdev).
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.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/20231004123422.6a161f021ae8.Ic8f40f2b4682270c94036e3c11c3996ae34266fa@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
set_antenna() is supported only when the device is not started in
mac80211 which translates to the firmware not being loaded in iwlwifi.
The tricky part is that iwlwifi populates the sband data during its boot
and doesn't touch this data afterwards, but if the antenna settings
forbid MIMO, we need to update the sband data.
Rework the nvm parsing code to allow to get an existing nvm_data and
modify the sband with additional constraints (tx / rx chains masks).
Suggested-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230921110726.81d94d630c95.I9473da818cbeeb51b2f89dcc59b00019113e7f55@changeid
[add bugfix from Benjamin for iwl_mvm_get_valid_rx_ant()]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
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@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There are a number of upcoming things in both the stack and
drivers that would otherwise conflict, so merge wireless to
wireless-next to be able to avoid those conflicts.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This reverts commit b70813e4a8 ("wifi: iwlwifi: update response
for mcc_update command") since it causes a merge conflict, and it
seems easier to redo the patch later.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
