Since the iwlmvm driver now only supports pre-MLO devices,
we no longer need to maintain an extra explicit link ID;
valid MAC IDs and link IDs are both in the range 0-3 and
the driver always has a 1:1 MAC/link correspondence. Thus,
simply use the MAC ID as the link ID as well.
This simplifies some further work because on RX the ID is
given but there is some confusion about which versions of
the firmware report MAC and which report link ID.
While at it, clarify iwl_mvm_handle_missed_beacons_notif()
code a bit so it doesn't look like an invalid vif pointer
is being used.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250711183056.005aa5fe34fe.Ib0c1187453f46ce49dc0f9f58907ee21f5b52634@changeid
There are a number of MAC parameters that are in the iwl_cfg
(which is the last config matched to the MAC/RF combination).
This isn't necessary, there are many more of those than MACs,
so move (most of) the data into the MAC family config struct.
Note that DCCM information remains for use by older devices,
and on 9000 series it'll be in struct iwl_cfg but be ignored
when the CRF is in a Qu/So platform.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20250508121306.1277801-15-miriam.rachel.korenblit@intel.com
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Cross-merge networking fixes after downstream PR (net-6.14-rc6).
Conflicts:
tools/testing/selftests/drivers/net/ping.py
75cc19c8ff ("selftests: drv-net: add xdp cases for ping.py")
de94e86974 ("selftests: drv-net: store addresses in dict indexed by ipver")
https://lore.kernel.org/netdev/20250311115758.17a1d414@canb.auug.org.au/
net/core/devmem.c
a70f891e0f ("net: devmem: do not WARN conditionally after netdev_rx_queue_restart()")
1d22d3060b ("net: drop rtnl_lock for queue_mgmt operations")
https://lore.kernel.org/netdev/20250313114929.43744df1@canb.auug.org.au/
Adjacent changes:
tools/testing/selftests/net/Makefile
6f50175cca ("selftests: Add IPv6 link-local address generation tests for GRE devices.")
2e5584e0f9 ("selftests/net: expand cmsg_ipv6.sh with ipv4")
drivers/net/ethernet/broadcom/bnxt/bnxt.c
661958552e ("eth: bnxt: do not use BNXT_VNIC_NTUPLE unconditionally in queue restart logic")
fe96d717d3 ("bnxt_en: Extend queue stop/start for TX rings")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
When MSI-X is not enabled, we mask all the interrupts in the interrupt
handler and re-enable them when the interrupt thread runs. If
STATUS_INT_ENABLED is not set, we won't re-enable in the thread.
In order to get the ALIVE interrupt, we allow the ALIVE interrupt
itself, and RX as well in order to receive the ALIVE notification (which
is received as an RX from the firmware.
The problem is that STATUS_INT_ENABLED is clear until the op_mode calls
trans_fw_alive which means that until trans_fw_alive is called, any
notification from the firmware will not be received.
This became a problem when we inserted the pnvm_load exactly between the
ALIVE and trans_fw_alive.
Fix that by calling trans_fw_alive before loading the PNVM. This will
allow to get the notification from the firmware about PNVM load being
complete and continue the flow normally.
This didn't happen on MSI-X because we don't disable the interrupts in
the ISR when MSI-X is available.
The error in the log looks like this:
iwlwifi 0000:00:03.0: Timeout waiting for PNVM load!
iwlwifi 0000:00:03.0: Failed to start RT ucode: -110
iwlwifi 0000:00:03.0: WRT: Collecting data: ini trigger 13 fired (delay=0ms).
Fixes: 70d3ca86b0 ("iwlwifi: mvm: ring the doorbell and wait for PNVM load completion")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@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/20250306122425.0f2cf207aae1.I025d8f724b44f52eadf6c19069352eb9275613a8@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The TOP is a shared (between BT and WiFi) hardware component,
and if it has an error we need to reset the whole device, i.e.
both BT and WiFi. This is achieved by calling a specific ACPI
DSM (device-specific method) with the right arguments before
doing a reset via the object referenced by _PRR.
Since this is needed here, but a function reset will always do
better than just re-enumerating the bus in case of errors, we
can always try to at least do a function reset and do the full
product reset only when needed for TOP errors.
Also, for some Bz and Sc devices where BT is PCIe/IOSF as well,
find the BT device and unbind that device as well so the BT
driver can recover from the reset that's going to happen,
rather than having to somehow detect that the device was reset.
Also add - currently unused - the function reset mode, this is
going to get used in the upcoming escalation model.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20241231135726.5b0f846d3e13.Ia14ccac38ac3d48adf5f341b17c7e34ccc41c065@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Kalle Valo says:
====================
wireless-next patches for v6.13
Most likely the last -next pull request for v6.13. Most changes are in
Realtek and Qualcomm drivers, otherwise not really anything
noteworthy.
Major changes:
mac80211
* EHT 1024 aggregation size for transmissions
ath12k
* switch to using wiphy_lock() and remove ar->conf_mutex
* firmware coredump collection support
* add debugfs support for a multitude of statistics
ath11k
* dt: document WCN6855 hardware inputs
ath9k
* remove include/linux/ath9k_platform.h
ath5k
* Arcadyan ARV45XX AR2417 & Gigaset SX76[23] AR241[34]A support
rtw88:
* 8821au and 8812au USB adapters support
rtw89
* thermal protection
* firmware secure boot for WiFi 6 chip
* tag 'wireless-next-2024-11-13' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (154 commits)
Revert "wifi: iwlegacy: do not skip frames with bad FCS"
wifi: mac80211: pass MBSSID config by reference
wifi: mac80211: Support EHT 1024 aggregation size in TX
net: rfkill: gpio: Add check for clk_enable()
wifi: brcmfmac: Fix oops due to NULL pointer dereference in brcmf_sdiod_sglist_rw()
wifi: Switch back to struct platform_driver::remove()
wifi: ipw2x00: libipw_rx_any(): fix bad alignment
wifi: brcmfmac: release 'root' node in all execution paths
wifi: iwlwifi: mvm: don't call power_update_mac in fast suspend
wifi: iwlwifi: s/IWL_MVM_INVALID_STA/IWL_INVALID_STA
wifi: iwlwifi: bump minimum API version in BZ/SC to 92
wifi: iwlwifi: move IWL_LMAC_*_INDEX to fw/api/context.h
wifi: iwlwifi: be less noisy if the NIC is dead in S3
wifi: iwlwifi: mvm: tell iwlmei when we finished suspending
wifi: iwlwifi: allow fast resume on ax200
wifi: iwlwifi: mvm: support new initiator and responder command version
wifi: iwlwifi: mvm: use wiphy locked debugfs for low-latency
wifi: iwlwifi: mvm: MLO scan upon channel condition degradation
wifi: iwlwifi: mvm: support new versions of the wowlan APIs
wifi: iwlwifi: mvm: allow always calling iwl_mvm_get_bss_vif()
...
====================
Link: https://patch.msgid.link/20241113172918.A8A11C4CEC3@smtp.kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When UATS isn't enabled (no VLP/AFC AP support), we need to still
set the right bits in the channel/regulatory flags, so remove the
uats_enabled argument to the parsing etc.
Also, firmware deals just fine with getting the UATS table if it
supports the command even if the bits aren't set, so always send
it, since it's also needed if BIT(31) is set, but the driver need
not have any knowledge of that. Remove 'uats_enabled' entirely.
Fixes: 0d2fc8821a ("wifi: iwlwifi: nvm: parse the VLP/AFC bit from regulatory")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20240618195731.a81e7234c4f6.Ic0131180d38e0f1ead2f7fa0e7583407ceaa0bd1@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>
Kalle Valo says:
====================
wireless-next patches for v6.11
The first "new features" pull request for v6.11 with changes both in
stack and in drivers. Nothing out of ordinary, except that we have
two conflicts this time:
net/mac80211/cfg.c
https://lore.kernel.org/all/20240531124415.05b25e7a@canb.auug.org.au
drivers/net/wireless/microchip/wilc1000/netdev.c
https://lore.kernel.org/all/20240603110023.23572803@canb.auug.org.au
Major changes:
cfg80211/mac80211
* parse Transmit Power Envelope (TPE) data in mac80211 instead of in drivers
wilc1000
* read MAC address during probe to make it visible to user space
iwlwifi
* bump FW API to 91 for BZ/SC devices
* report 64-bit radiotap timestamp
* enable P2P low latency by default
* handle Transmit Power Envelope (TPE) advertised by AP
* start using guard()
rtlwifi
* RTL8192DU support
ath12k
* remove unsupported tx monitor handling
* channel 2 in 6 GHz band support
* Spatial Multiplexing Power Save (SMPS) in 6 GHz band support
* multiple BSSID (MBSSID) and Enhanced Multi-BSSID Advertisements (EMA)
support
* dynamic VLAN support
* add panic handler for resetting the firmware state
ath10k
* add qcom,no-msa-ready-indicator Device Tree property
* LED support for various chipsets
* tag 'wireless-next-2024-06-07' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (194 commits)
wifi: ath12k: add hw_link_id in ath12k_pdev
wifi: ath12k: add panic handler
wifi: rtw89: chan: Use swap() in rtw89_swap_sub_entity()
wifi: brcm80211: remove unused structs
wifi: brcm80211: use sizeof(*pointer) instead of sizeof(type)
wifi: ath12k: do not process consecutive RDDM event
dt-bindings: net: wireless: ath11k: Drop "qcom,ipq8074-wcss-pil" from example
wifi: ath12k: fix memory leak in ath12k_dp_rx_peer_frag_setup()
wifi: rtlwifi: handle return value of usb init TX/RX
wifi: rtlwifi: Enable the new rtl8192du driver
wifi: rtlwifi: Add rtl8192du/sw.c
wifi: rtlwifi: Constify rtl_hal_cfg.{ops,usb_interface_cfg} and rtl_priv.cfg
wifi: rtlwifi: Add rtl8192du/dm.{c,h}
wifi: rtlwifi: Add rtl8192du/fw.{c,h} and rtl8192du/led.{c,h}
wifi: rtlwifi: Add rtl8192du/rf.{c,h}
wifi: rtlwifi: Add rtl8192du/trx.{c,h}
wifi: rtlwifi: Add rtl8192du/phy.{c,h}
wifi: rtlwifi: Add rtl8192du/hw.{c,h}
wifi: rtlwifi: Add new members to struct rtl_priv for RTL8192DU
wifi: rtlwifi: Add rtl8192du/table.{c,h}
...
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
====================
Link: https://lore.kernel.org/r/20240607093517.41394C2BBFC@smtp.kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
dmi_get_system_info() will statically return NULL when the
kernel is compiled without CONFIG_DMI, leading to compiler
warnings. Fix that by printing "<unknown>" in that case.
Fixes: c3f40c3e02 ("iwlwifi: mvm: add US/CA to TAS block list if OEM isn't allowed")
Fixes: 9457077df4 ("wifi: iwlwifi: mvm: Add debugfs to get TAS status")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
