Replace the ifdef CONFIG_PM by CONFIG_PM_SLEEP. CONFIG_PM was useful
when we had CONFIG_PM_RUNTIME but that was removed long ago.
Use PM_SLEEP consistently across the driver.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240825191257.44e47ba584de.I64f985d0405345252b76b7157291b79677abd64d@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
mwifiex has recently started to see active development which is good
news. rtw89 is also under active development and got several new
features. Otherwise not really anything out of ordinary.
We have one conflict in ath12k but that's easy to fix:
https://lore.kernel.org/all/20240808104348.6846e064@canb.auug.org.au/
Major changes:
mwifiex
* support for up to ten Authentication and Key Management (AKM) suites
* host MAC Sublayer Management Entity (MLME) client and AP mode support
* WPA-PSK-SHA256 AKM suite support
rtw88
* improve USB performance by aggregation
rtw89
* Wi-Fi 6 chip RTL8852BE-VT support
* WoWLAN net-detect support
* hardware encryption in unicast management frames support
* hardware rfkill support
ath12k
* DebugFS support for transmit DE stats
* Make ASPM support hardware-dependent
iwlwifi
* channel puncturing for US/CAN from UEFI
* bump FW API to 93 for BZ/SC devices
-----BEGIN PGP SIGNATURE-----
iQFFBAABCgAvFiEEiBjanGPFTz4PRfLobhckVSbrbZsFAmbYfCARHGt2YWxvQGtl
cm5lbC5vcmcACgkQbhckVSbrbZt+Qwf/X9oQ4sf8jV6eOV7EhoWhIHnQadvo5YBZ
ulBm8In0QGjEOVWkI7kXGabKP5jhne2lVIyP1eFfP2/td/A2yDWIuEeBfDQD6f4K
aiUGAa1gs4ZtGKJBniw/ukflSqJlR99N2qBO5T/smDm3Nw/aC522SO7BoLTpoJDQ
SuW4atFHMShXYf/vIrAA2yB9ok2yw/QM+27M9qjj6D7zzqsQxDl9wKGW+2v8KiSa
rXXbfnwfaQP21CYv5xYbEPACSRSV5Dr0TNopivWYxmm9svjLzwFN2JM2fHPxBEDh
wP6Ojp+Z32c1VbQtclLrwIQdlZ5yhU5MEDlVg5VLym9F83hv+oXTbA==
=lgVx
-----END PGP SIGNATURE-----
Merge tag 'wireless-next-2024-09-04' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next
Kalle Valo says:
====================
pull-request: wireless-next-2024-09-04
here's a pull request to net-next tree, more info below. Please let me know if
there are any problems.
====================
Conflicts:
drivers/net/wireless/ath/ath12k/hw.c
38055789d1 ("wifi: ath12k: use 128 bytes aligned iova in transmit path for WCN7850")
8be12629b4 ("wifi: ath12k: restore ASPM for supported hardwares only")
https://lore.kernel.org/87msldyj97.fsf@kernel.org
Link: https://patch.msgid.link/20240904153205.64C11C4CEC2@smtp.kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
We used to have the opmode configuring it to the trans according to the
debug tlv value (FW_DBG_TRIGGER_TXQ_TIMERS).
But this debug is not used, so trans can just have the default value
hardcoded.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240808232017.87af3f063025.I2222981ead13f6a917f2d4b116c5b94200dc9e51@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Use the same handler for both types and just convert the old version to
the new. Drop the unused fields from the old one and fake the new
fields.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240808232017.a64ffc998569.I7d181052b1a69c331d07263f20c1e00cbc0bc891@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
A new version is coming up. Rename the current struct to include the
current version.
s/iwl_missed_beacons_notif/iwl_missed_beacons_notif_v4
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240808232017.b5c3a83a05ef.I698611582b5ca8395f42a535c51f7230307e2c6f@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Currently, the driver handles SMPS decisions by tracking AP
capabilities, BT coexistence changes, sending necessary SMPS
frames to the AP, and updating firmware with RX chain info
using the RLC_CONFIG_CMD.
Starting with version 3 of the RLC_CONFIG_CMD, the firmware
takes over this responsibility. It now tracks SMPS, sends
frames, and configures the RLC.
In this patch:
1. Stop sending RLC_CONFIG_CMD when firmware supports RLC
offload (version 3), as rlc.rx_chain_info is not needed by
firmware, and no other field in the cmd is used.
2. Prevent the driver from forwarding any SMPS requests to
mac80211, i.e., the driver should not transmit SMPS frames
to the AP as firmware handles that.
3. Set NL80211_FEATURE_DYNAMIC_SMPS and NL80211_FEATURE_STATIC_SMPS
conditionally based on RLC version.
Signed-off-by: Daniel Gabay <daniel.gabay@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240808232017.45da23be1f65.I0d46db82dd990a82e8a66876fe2f5310bc9513be@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We have a new notification the BT profile. It contains almost nothing,
only the wifi loss information. Copy this into mvm. We still need to
iterate over the vifs / links to use this data.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240729201718.637499f3a85a.I8bf654cf5d8aa038100273876c936845ecc338f7@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The iwl_bt_coex_profile_notif is now being obsoleted. It'll be replaced
by a new notification coming with a non-legacy group. Rename it to avoid
confusion.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240729201718.dc29fd0d7817.I5881fce86ec8b76ae98d2948265434b8e7d860c1@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Not doing so will make us send a host command to the transport while the
firmware is not alive, which will trigger a WARNING.
bad state = 0
WARNING: CPU: 2 PID: 17434 at drivers/net/wireless/intel/iwlwifi/iwl-trans.c:115 iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]
RIP: 0010:iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]
Call Trace:
<TASK>
iwl_mvm_send_cmd+0x40/0xc0 [iwlmvm]
iwl_mvm_config_scan+0x198/0x260 [iwlmvm]
iwl_mvm_recalc_tcm+0x730/0x11d0 [iwlmvm]
iwl_mvm_tcm_work+0x1d/0x30 [iwlmvm]
process_one_work+0x29e/0x640
worker_thread+0x2df/0x690
? rescuer_thread+0x540/0x540
kthread+0x192/0x1e0
? set_kthread_struct+0x90/0x90
ret_from_fork+0x22/0x30
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240825191257.5abe71ca1b6b.I97a968cb8be1f24f94652d9b110ecbf6af73f89e@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
iwl_mvm_select_links is called by the link selection worker and it
requires the mutex.
Take it in the link selection worker.
This logic used to run from iwl_mvm_rx_umac_scan_complete_notif which
had the mvm->mutex held. This was changed to run in a worker holding the
wiphy mutex, but we also need the mvm->mutex.
Fixes: 2e194efa38 ("wifi: iwlwifi: mvm: Fix race in scan completion")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240825191257.0cacecd5db1e.Iaca38a078592b69bdd06549daf63408ccf1810e4@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Fast resume is a feature that was recently introduced to speed up the
resume time. It basically keeps the firmware alive while the system
is suspended and that avoids starting again the whole device.
This flow can't work for hibernation, since when the system boots,
before the frozen image is loaded, the kernel may touch the device. As a
result, we can't assume the device is in the exact same state as before
the hibernation.
Detect that we are resuming from hibernation through the PCI device and
forbid the fast resume flow. We also need to shut down the device
cleanly when that happens.
In addition, in case the device is power gated during S3, we won't be
able to keep the device alive. Detect this situation with BE200 at least
with the help of the CSR_FUNC_SCRATCH register and reset the device upon
resume if it was power gated during S3.
Fixes: e8bb19c1d5 ("wifi: iwlwifi: support fast resume")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240825191257.24eb3b19e74f.I3837810318dbef0a0a773cf4c4fcf89cdc6fdbd3@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
iwl_mvm_get_bss_vif might return a NULL or ERR_PTR. Some of the callers
check only the NULL case, and some doesn't check at all.
Some of the callers even have a pointer to the mvmvif of the bss vif,
so we don't even need to call this function, and can simply get the vif
from mvmvif. Do it for those cases, and for the others - properly check
if IS_ERR_OR_NULL
Fixes: ec0d43d26f ("wifi: iwlwifi: mvm: Activate EMLSR based on traffic volume")
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240703064027.a661f8c65aac.I45cf09b01af8ee3d55828863958ead741ea43b7f@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Since we now want to sync the queues even when we're in RFKILL, we
shouldn't wake up the wait queue since we still expect to get all the
notifications from the firmware.
Fixes: 4d08c0b335 ("wifi: iwlwifi: mvm: handle BA session teardown in RF-kill")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240703064027.be7a9dbeacde.I5586cb3ca8d6e44f79d819a48a0c22351ff720c9@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
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@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This is the first step towards removing the P2P Device MAC.
Use ROC (which uses the AUX MAC) for P2P Device
discoveribility and action frames.
Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240605140556.8c90e457abbd.I8e340759ecb299e05b1809f3d8060429c6cbbd01@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The code that is parsing the amsdu_size module parameter and mapping it
to the corresponding Rx buffer size is common to all opmodes.
Move it into a function in iwlwifi, as preparation to a new op mode we
are working on.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://msgid.link/20240527190228.a3430d32923d.Iab3c22ef0df685f72f22dafc47021f0dc7bd6fa5@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Upon start, the different opmodes are currently printing:
1. HW rev, which is already print by iwlwifi
2. The HW name (e.g. "Intel(R) Wi-Fi 7 BE201 320MHz")
cleanup things such as the hw rev won't be printed again, the HW name will
be printed by iwlwifi instead of each opmode.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://msgid.link/20240527190228.5c589c7abed0.I3590c4ee0ee99d1b207852c32d25d326afb327dd@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
fw_running assumes that memory can be retrieved only after alive.
This assumption is no longer true as we support dump before alive.
To avoid invalid access to the NIC, check that STATUS_DEVICE_ENABLED
bit in trans status is set before dumping instead of the prior check.
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Reviewed-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240510170500.ca07138cedeb.I090e31d3eaeb4ba19f5f84aba997ccd36927e9ac@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
While doing a passive scan, the firmware will report per-channel survey
information. This information is primarily useful for hostapd when doing
an ACS (Automatic Channel Selection). Collect this information and add
it to the result set when getting the survey information.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240506095953.9287591a5999.I54a3f9f6480d3694e67eea1cb4f5853beace2780@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When requested, the firmware can return per-channel survey information
generally used for ACS (automatic channel selection). Add the API for
this, which consists of a flag and a new channel survey notification.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240506095953.1facde532676.I3864ac4bc0fecb7fd5136e85c07585ab7100234b@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The move of the scan complete notification handling to the wiphy worker
introduced a race between scan complete notification and scan abort:
- The wiphy lock is held, e.g., for rfkill handling etc.
- Scan complete notification is received but not handled yet.
- Scan abort is triggered, and scan abort is sent to the FW. Once the
scan abort command is sent successfully, the flow synchronously waits
for the scan complete notification. However, as the scan complete
notification was already received but not processed yet, this hangs for
a second and continues leaving the scan status in an inconsistent
state.
- Once scan complete handling is started (when the wiphy lock is not held)
since the scan status is not an inconsistent state, a warning is issued
and the scan complete notification is not handled.
To fix this issue, switch back the scan complete notification to be
asynchronously handling, and only move the link selection logic to
a worker (which was the original reason for the move to use wiphy lock).
While at it, refactor some prints to improve debug data.
Fixes: 07bf5297d3 ("wifi: iwlwifi: mvm: Implement new link selection algorithm")
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240506095953.1f484a86324b.I63ed445a47f144546948c74ae6df85587fdb4ce3@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When there's an active link in a non-station vif, the station vif is
not allowed to enter EMLSR
Note that blocking EMLSR by calling iwl_mvm_block_esr() we will schedule
an exit from EMLSR worker, but the worker cannot run before the
activation of the non-BSS link, as ieee80211_remain_on_channel already
holds the wiphy mutex.
Handle that by explicitly calling ieee80211_set_active_links()
to leave EMLSR, and then doing iwl_mvm_block_esr() only for
consistency and to avoid re-entering it before ready.
Note that a call to ieee80211_set_active_links requires to release the
mvm mutex, but that's ok since we still hold the wiphy lock. The only
thing that might race here is the ESR_MODE_NOTIF, so this changes its
handler to run under the wiphy lock.
Signed-off-by: Yedidya Benshimol <yedidya.ben.shimol@intel.com>
Co-developed-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240505091420.916193759f8a.Idf3a3caf5cdc3e69c81710b7ceb57e87f2de87e4@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Replaces the current logic with a new algorithm based on the link
grading introduced in a previous patch.
The new selection algorithm will be invoked upon successful scan to ensure
it has the necessary updated data it needs.
This update delegates the selection logic as the primary link
determiner in EMLSR mode, storing it in mvmvif to avoid repeated
calculations, as the result may vary.
Additionally, includes tests for iwl_mvm_valid_link_pair to validate
link pairs for EMLSR.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://msgid.link/20240416134215.309fb1b3fe44.I5baf0c293c89a5a28bd1a6386bf9ca6d2bf61ab8@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Send AP_TX_POWER_CONSTRAINTS_CMD with no local maximum transmit
power constraint to FW and FW will update the TPE element with
required tx power limits.
Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240416134215.b6af4ecfcfe8.I07e8db349190e0c58c468c18477d8551288ac069@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
With C99 bool we really also should use true/false, not the
upper-case variants, wherever they may actually be coming
from. Fix that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240208185302.5732dd306ee9.Ifc07c026ac3779429e3dc949e96c9437e89f7bf9@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
CT kill should stop doing a lot of TX etc. to cool down the
NIC, but we don't stop all commands from going to the NIC,
and as such we shouldn't abort queue sync, since it can get
confused if we do, warning that we do it twice at the same
time etc. Only stop it when we'd also not send it in the
first place.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240205211151.4e0745e2cd97.I311dc623ce68de6a2da3c21c8d84a387844f714a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
For channel contexts, mac80211 currently uses the cfg80211
chandef struct (control channel, center freq(s), width) to
define towards drivers and internally how these behave. In
fact, there are _two_ such structs used, where the min_def
can reduce bandwidth according to the stations connected.
Unfortunately, with EHT this is longer be sufficient, at
least not for all hardware. EHT requires that non-AP STAs
that are connected to an AP with a lower bandwidth than it
(the AP) advertises (e.g. 160 MHz STA connected to 320 MHz
AP) still be able to receive downlink OFDMA and respond to
trigger frames for uplink OFDMA that specify the position
and bandwidth for the non-AP STA relative to the channel
the AP is using. Therefore, they need to be aware of this,
and at least for some hardware (e.g. Intel) this awareness
is in the hardware. As a result, use of the "same" channel
may need to be split over two channel contexts where they
differ by the AP being used.
As a first step, introduce a concept of a channel request
('chanreq') for each interface, to control the context it
requests. This step does nothing but reorganise the code,
so that later the AP's chandef can be added to the request
in order to handle the EHT case described above.
Link: https://msgid.link/20240129194108.2e88e48bd2e9.I4256183debe975c5ed71621611206fdbb69ba330@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Try to read the SPLC table from UEFI first,
and if the WIFI UEFI tables are unlocked or the
table doesn't exist - try to read it from ACPI
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://msgid.link/20240201155157.3d9d835b6edb.I7ea262df9431ced787b77c87149c6d7bddb7e7d6@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
As the iwl_bios_get_x() functions are now generated using a macro,
and this macro requires the all iwl_acpi_get_x() to have the same
prototype, change iwl_acpi_get_pwr_limit() to return a int
and the actuall power limit will be filled in a pointer function
parameter.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://msgid.link/20240201155157.4cce81198afe.Ice8b1b97a68da9ec7b5a4799ddb668642198e1af@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
All the regulatory tables will be read from UEFI, and
only if it doesn't exist - they will be read from ACPI.
Read SAR tables (WRDS, EWRD and WGDS) from UEFI.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://msgid.link/20240131091413.533b687e1efb.Icb316291e593c8d53f41fdea2d083367dc97e3c4@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
eSR should be disabled when BT Coex is active and:
- LB link is the primary link.
- LB link is the secondary link and the predicted BT penalty
(the wifi loss rate caused by BT interference) is higher
than a given threshold.
If one of the conditions above is no longer true then re-enable eSR.
In order to implement this, add support for version 5 of
BT_PROFILE_NOTIFICATION, in which the bt penalty is provided
by FW.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://msgid.link/20240131225342.b922b6485af8.I7d808ce535a7372aca9cb85c045755e6788a4904@changeid
Signed-off-by: Johannes Berg <johannes.berg@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>
There's only one user of this code, which is STA unblock
during sleep for uAPSD on really old devices. Instead of
having this all through the API with calls up and down,
just implemented a special-case CMD_BLOCK_TXQS flag for
this, it's only needed in the old gen1 transport.
While at it, fix a complain that lockdep would have, as
we lock the cmd queue and then the TXQs in the reclaim
by using spin_lock_nested(). We no longer need to disable
BHs in iwl_trans_pcie_block_txq_ptrs() since it's called
with them disabled already.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20231207044813.2bd95e0570fc.I16486dbc82570d2f73a585872f5394698627310d@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The new firmware API uses a new command and notification,
the command configures in which statistics types driver is
interested and the notification is sent periodically.
An additional change in the API is that most of the statistics
data is accumulated and reported by the firmware per MLO link.
Implement new command and notification handlers and adjust to
per-link statistics.
Signed-off-by: Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20231022173519.8cc7df0ebff2.If1dcb57145841c5b3c68ed112bbfcd0201f7acc3@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In reality 64 bytes are enough to hold fw version string,
but some compilers can complain (with W=1) that output may be
truncated when building this string with snprintf.
Increase the size to avoid this sort of warnings and state
explicitely that we want the size to be trancated to 32 bytes.
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Tested-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231012153950.f4465b4b4e2b.Idced2e8d63c492872edcde1a3ce2cdd6cc0f8eb7@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Emmanuel Grumbach
Jakub Kicinski
Miri Korenblit
Daniel Gabay
Somashekhar(Som)
Johannes Berg
Shaul Triebitz
Shahar S Matityahu
Benjamin Berg
Ilan Peer
Yedidya Benshimol
Mukesh Sisodiya
Anjaneyulu
Gregory Greenman