- Mar 26, 2025
-
-
Jeff Johnson authored
-
Johan Hovold authored
Extend the DMA mask to 36 bits to avoid using bounce buffers on machines without an iommu (under OS control) similar to what was done for ath11k in commit dbd73acb ("wifi: ath11k: enable 36 bit mask for stream DMA"). This specifically avoids using bounce buffers on Qualcomm Snapdragon X Elite machines like the Lenovo ThinkPad T14s when running at EL1. Note that the mask could possibly be extended further but unresolved DMA issues with 64 GiB X Elite machines currently prevents that from being tested. Also note that the driver is limited to 32 bits for coherent allocations and that there is no need to check for errors when setting masks larger than 32 bits. Tested-on: WCN7850 hw2.0 WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Signed-off-by:
Johan Hovold <johan+linaro@kernel.org> Tested-by:
Raj Kumar Bhagat <quic_rajkbhag@quicinc.com> Reviewed-by:
Baochen Qiang <quic_bqiang@quicinc.com> Tested-by:
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
-
- Mar 25, 2025
-
-
P Praneesh authored
Currently, the monitor interface is not supported. To support the monitor interface, configure the monitor vdev state identifier, configure the HTT filter setup, subscribe the mac80211 NO_VIRTUAL_MONITOR feature, remove the VIRTUAL_MONITOR handler procedures since align to NO_VIRTUAL_MONITOR feature and prevent monitor interface to transmit packet. Therefore, add these procedures to add monitor interface support and enable the monitor interface support on the QCN9274 platform through the hardware parameter. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by:
P Praneesh <quic_ppranees@quicinc.com> Signed-off-by:
Karthikeyan Periyasamy <quic_periyasa@quicinc.com> Reviewed-by:
Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250324062518.2752822-11-quic_periyasa@quicinc.com Signed-off-by:
-
Karthikeyan Periyasamy authored
Currently, VIRTUAL monitor handling is present. In multi radio model, VIRTUAL monitor is not suitable since each radio needs a separate VIF and channel context. Therefore, switch to NO_VIRTUAL_MONITOR feature. Remove the monitor_conf_enabled flag and mac_op_config() handler as they are not need for the NO_VIRTUAL_MONITOR feature. In NO_VIRTUAL_MONITOR handling, each interface creation/deletion triggers the mac_op_add_interface() / mac_op_remove_interface() callback. Consequently, remove the monitor vdev create/delete/start/stop from the other vdev type handlers. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by:
-
Karthikeyan Periyasamy authored
Currently, the monitor start procedure use the iteration callback to pick the last available channel definition in the mac80211 hardware. This approach is incorrect for the single wiphy model, as it holds multiple radio/link channel contexts within the same mac80211 hardware. To fix this, change the iteration callback to pick the specific channel context for the given radio/link. This approach makes the monitor start procedure compatible with both multi wiphy and single wiphy models. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Reviewed-by:
-
Karthikeyan Periyasamy authored
Currently, when ath12k_mac_assign_vif_to_vdev() fails, the radio handle (ar) gets accessed from the link VIF handle (arvif) for debug logging, This is incorrect. In the fail scenario, radio handle is NULL. Fix the NULL access, avoid radio handle access by moving to the hardware debug logging helper function (ath12k_hw_warn). Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: 90570ba4 ("wifi: ath12k: do not return invalid link id for scan link") Reviewed-by:
-
P Praneesh authored
Currently, the packet offset and FCS length are fetched from the MSDU Rx TLV data, a logic inherited from ath11k. However, for ath12k 802.11be hardware, the Rx TLV will not be present in the MSDU data. Instead, this information is constant. Therefore, remove the existing FCS trim and the packet offset fetch code. Handle the packet offset with the constant in the merge MSDU procedure. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by:
Nicolas Escande <nico.escande@gmail.com> Reviewed-by:
-
P Praneesh authored
Currently, in the monitor Rx path, status is filled from the RX TLV header present in the MSDU data. This logic is inherited from ath11k. However, in the ath12k 802.11be hardware, the Rx TLV header is not present in the MSDU data. This information is reported under various TLV tags. Therefore, avoid the existing status filling by accumulating the needed information in the PPDU information structure and fill the status. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by:
-
Karthikeyan Periyasamy authored
Currently, band define and enum are with the word 'G'. Replace it with more appropriate 'GHZ' for clarity and correctness. No functional changes. Only compile tested. Reviewed-by:
-
P Praneesh authored
Currently, error bitmap and decap format information are fetched from the MSDU Rx TLV data. This logic is inherited from ath11k. However, for ath12k 802.11be hardware, the Rx TLV will not be present in the MSDU data. Instead, this information is reported separately under the MSDU END TLV tag. Therefore, remove the existing fetch code, handle the MSDU END TLV tag and fetch the above information to store it in the mon_mpdu data structure for use in the merge MSDU procedure. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by:
-
P Praneesh authored
Currently, the monitor Rx parser handler is inherited from the ath11k. However, the ath12k 802.11be hardware does not report the Rx TLV header in the MSDU data. Instead, the hardware reports those TLVs under the following TLV tags: 1. Buffer address 2. MPDU start 3. MPDU end 4. MSDU end Therefore, add support for parsing the above TLVs in the Rx monitor path and use this information for MSDU buffer and status updates. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by:
-
Hari Chandrakanthan authored
Currently, the link_valid field is not initialized in the monitor Rx path. This can result in random values for the link_valid and link_id leads to undefined behaviour in mac80211. Therefore, initialize the link_valid field in the monitor Rx path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by:
Hari Chandrakanthan <quic_haric@quicinc.com> Tested-by:
-
Jeff Johnson authored
Signed-off-by: -
Jeff Johnson authored
-
Jeff Johnson authored
-
Balamurugan S authored
Currently only PCI devices are supported in Ath12k driver. Refactor Ath12k module_init and module_exit to include Ath12k AHB support. Add Ath12k AHB support in Kconfig with dependency on Remoteproc driver. Ath12k AHB support relies on remoteproc driver for firmware download, power up/down etc. Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.3.1-00130-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00210-QCAHKSWPL_SILICONZ-1 Signed-off-by:
Balamurugan S <quic_bselvara@quicinc.com> Co-developed-by:
-
Sowmiya Sree Elavalagan authored
Set the stop bit in SMEM to power down the userPD. Wait for stop-ack IRQ to indicate power down completion. Release the userPD firmware using its peripheral ID. Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.3.1-00130-QCAHKSWPL_SILICONZ-1 Signed-off-by:
Sowmiya Sree Elavalagan <quic_ssreeela@quicinc.com> Reviewed-by:
-
Sowmiya Sree Elavalagan authored
UserPD firmware image is loaded and booted by ath12k driver. Get the userPD memory region from DTS and load the firmware for userPD from pre-defined path into io-remapped address of this region. Authenticate this image using pasid which is a peripheral ID. Set the spawn bit to instruct Q6 to spawn userPD thread. Wait for userPD to spawn which is indicated by spawn interrupt. Ready interrupt is triggered once the userPD is powered up completely. Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.3.1-00130-QCAHKSWPL_SILICONZ-1 Signed-off-by:
-
Sowmiya Sree Elavalagan authored
Q6 and ath12k driver communicates using SMEM and IRQs. Spawn interrupt is triggered once the userPD thread is spawned. Ready interrupts denotes userPD is completely powered up and ready. Stop-ack is to acknowledge the ath12k driver that userPD is stopped. Ath12k driver needs to set spawn bit in SMEM to instruct Q6 to spawn a userPD. Similarly stop bit is set when userPD needs to be stopped. Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.3.1-00130-QCAHKSWPL_SILICONZ-1 Signed-off-by:
-
Sowmiya Sree Elavalagan authored
Q6 processor acts as rootPD, other hardware like IPQ5332 which are attached to Q6 act as userPDs. WCSS driver handles loading and booting of rootPD, while the ath12k driver boots the userPD. Get the rproc handle from the DTS entry and boot the rootPD if it is not already powered on. Register to the rproc notifier to monitor the rproc state, this allows ath12k driver to know power up/down sequence of the rootPD. Power up the rootPD and wait for a power-up notification from the notifier callback before powering up the userPDs. Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.3.1-00130-QCAHKSWPL_SILICONZ-1 Signed-off-by:
-
Balamurugan S authored
Add Initial Ath12k AHB driver support for IPQ5332. IPQ5332 is AHB based IEEE802.11be 2 GHz 2x2 WiFi device. Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.3.1-00130-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00210-QCAHKSWPL_SILICONZ-1 Signed-off-by:
-
Raj Kumar Bhagat authored
IPQ5332 firmware supports only fixed QMI firmware memory. Hence, add support to read reserved fixed memory region from device-tree and provide the reserved memory segments for firmware to use during QMI firmware memory request. Note that the ability to set the fixed memory will be introduced in a subsequent patch. Currently, the flag remains unset by default, ensuring that existing chipsets are unaffected. Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.3.1-00130-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00210-QCAHKSWPL_SILICONZ-1 Reviewed-by:
-
Balamurugan S authored
For IPQ5332 CE register space is moved out of WCSS region and the space is not contiguous. Hence, add hardware params (ce_ie_addr & ce_remap) for IPQ5332. These parameters would be used by Ath12k AHB driver (in subsequent patches) to remap the CE registers to a new space for accessing them. Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.3.1-00130-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00210-QCAHKSWPL_SILICONZ-1 Signed-off-by:
-
Balamurugan S authored
Current ath12k devices, QCN9274 and WCN7850, supports m3.bin firmware download through ath12k driver. The new ath12k AHB based device IPQ5332 supports m3 firmware download through remoteproc driver. Hence, add new parameter (fw.m3_loader) in ath12k_hw_params to avoid m3 firmware download in IPQ5332. Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.3.1-00130-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00210-QCAHKSWPL_SILICONZ-1 Signed-off-by:
-
Balamurugan S authored
Add ath12k_hw_params for new ath12k AHB based WiFi device IPQ5332. Some hardware parameters like hw_ops, wmi_init & hal_ops are same between IPQ5332 and QCN9274, hence use these same parameters for IPQ5332. Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.3.1-00130-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00210-QCAHKSWPL_SILICONZ-1 Signed-off-by:
-
P Praneesh authored
IPQ5332 device have different register address values for the below registers: HAL_TCL1_RING_BASE_LSB HAL_TCL1_RING_BASE_MSB HAL_TCL2_RING_BASE_LSB HAL_SEQ_WCSS_UMAC_CE0_SRC_REG HAL_SEQ_WCSS_UMAC_CE0_DST_REG HAL_SEQ_WCSS_UMAC_CE1_SRC_REG HAL_SEQ_WCSS_UMAC_CE1_DST_REG Hence, refactor ath12k_hw_regs structure to accommodate these changes in IPQ5332. Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.3.1-00130-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00210-QCAHKSWPL_SILICONZ-1 Signed-off-by:
-
Balamurugan S authored
In the current ath12k implementation, the CE addresses CE_HOST_IE_ADDRESS and CE_HOST_IE_2_ADDRESS are incorrect. These values were inherited from ath11k, but ath12k does not currently use them. However, the Ath12k AHB support relies on these addresses. Therefore, correct the CE addresses for ath12k. Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.3.1-00130-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00210-QCAHKSWPL_SILICONZ-1 Signed-off-by:
-
Raj Kumar Bhagat authored
Add device-tree bindings for the ATH12K module found in the IPQ5332 device. Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Baochen Qiang authored
ieee80211_chanctx_conf struct is not put at the end of ath12k_link_vif. Note ieee80211_chanctx_conf has flexible array member inside it, causing below warning with GCC-14: drivers/net/wireless/ath/ath12k/core.h:298:39: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] Although there is no issue for now since the array is not getting used, this should be fixed to avoid any potential data corruption issue in the future. Remove this struct from ath12k_link_vif, fetch it from ieee80211_bss_conf instead when needed. This change only applies to WCN7850, and should has no impact on other chipsets. This is an alternative to the solution proposed in [1]. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Reported-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Closes: https://msgid.link/Z8-Snz86Xfwdlyd7@kspp # [1] Signed-off-by:
-
- Mar 17, 2025
-
-
Muna Sinada authored
PMF debug log has an open parenthesis that is not needed. Remove open parenthesis. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by:
Muna Sinada <muna.sinada@oss.qualcomm.com> Link: https://patch.msgid.link/20250314185605.68454-1-muna.sinada@oss.qualcomm.com Signed-off-by:
-
Kees Cook authored
When a character array without a terminating NUL character has a static initializer, GCC 15's -Wunterminated-string-initialization will only warn if the array lacks the "nonstring" attribute[1]. Mark the arrays with __nonstring to and correctly identify the char array as "not a C string" and thereby eliminate the warning. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178 [1] Cc: Christian Lamparter <chunkeey@googlemail.com> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: linux-wireless@vger.kernel.org Signed-off-by:
Kees Cook <kees@kernel.org> Acked-by:
Christian Lamparter <chunkeey@gmail.com> Link: https://patch.msgid.link/20250310222339.work.654-kees@kernel.org Signed-off-by:
-
Aditya Kumar Singh authored
Driver does not support get_txpower mac ops because of which cfg80211 returns vif->bss_conf.txpower to user space. bss_conf.txpower gets its value from ieee80211_channel->max_reg_power. However, the final txpower is dependent on few other parameters apart from max regulatory supported power. It is the firmware which knows about all these parameters and considers the minimum for each packet transmission. All ath12k firmware reports the final TX power in firmware pdev stats which falls under fw_stats. add get_txpower mac ops to get the TX power from firmware leveraging fw_stats and return it accordingly. While at it, there is a possibility that repeated stats request WMI commands are queued to FW if mac80211/userspace does get tx power back to back(in Multiple BSS cases). This could potentially consume the WMI queue completely. Hence limit this by fetching the power only for every 5 seconds and reusing the value until the refresh timeout or when there is a change in channel. Also remove init_completion(&ar->fw_stats_complete) in ath12k_mac_hw_register() as ath12k_fw_stats_init() takes care of it for each ar. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by:
Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Signed-off-by:
Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by:
Mahendran P <quic_mahep@quicinc.com> Link: https://patch.msgid.link/20250306102215.1300522-3-rameshkumar.sundaram@oss.qualcomm.com Signed-off-by:
-
Aditya Kumar Singh authored
Currently, firmware stats, comprising pdev, vdev and beacon stats are part of debugfs. In firmware pdev stats, firmware reports the final Tx power used to transmit each packet. If driver wants to know the final Tx power being used at firmware level, it can leverage from firmware pdev stats. Move firmware stats out of debugfs context in order to leverage the final Tx power reported in it even when debugfs is disabled. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by:
-
Sriram R authored
Currently, for 320 MHz bandwidth, center frequency1 and center frequency2 are not passed correctly to the firmware. Set center frequency1 as the center frequency of the primary 160 MHz channel segment and center frequency2 as the center frequency of the 320 MHz channel and pass the values to the firmware. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Signed-off-by:
Sriram R <quic_srirrama@quicinc.com> Signed-off-by:
Suraj P Kizhakkethil <quic_surapk@quicinc.com> Reviewed-by:
-
Suraj P Kizhakkethil authored
Currently, for 160 MHz bandwidth, center frequency1 and center frequency2 are not passed correctly to the firmware. Set center frequency1 as the center frequency of the primary 80 MHz channel segment and center frequency2 as the center frequency of the 160 MHz channel and pass the values to the firmware. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Signed-off-by:
-
- Mar 14, 2025
-
-
A client driver may use mhi_unprepare_from_transfer() to quiesce incoming data during the client driver's tear down. The client driver might also be processing data at the same time, resulting in a call to mhi_queue_buf() which will invoke mhi_gen_tre(). If mhi_gen_tre() runs after mhi_unprepare_from_transfer() has torn down the channel, a panic will occur due to an invalid dereference leading to a page fault. This occurs because mhi_gen_tre() does not verify the channel state after locking it. Fix this by having mhi_gen_tre() confirm the channel state is valid, or return error to avoid accessing deinitialized data. Cc: stable@vger.kernel.org # 6.8 Fixes: b89b6a86 ("bus: mhi: host: Add spinlock to protect WP access when queueing TREs") Signed-off-by:
Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by:
Jeff Hugo <jeff.hugo@oss.qualcomm.com> Reviewed-by:
Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Reviewed-by:
Youssef Samir <quic_yabdulra@quicinc.com> Reviewed-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by:
Troy Hanson <quic_thanson@quicinc.com> Link: https://lore.kernel.org/r/20250306172913.856982-1-jeff.hugo@oss.qualcomm.com [mani: added stable tag] Signed-off-by:
-
- Mar 07, 2025
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/ath/athJohannes Berg authored
Jeff Johnson says: ==================== ath.git patches for v6.15 This development cycle again featured multiple patchsets to ath12k to support the new 802.11be MLO feature. In addition, there was the usual set of bug fixes and cleanups. ==================== Link: https://lore.kernel.org/linux-wireless/d01b1976-ebe8-48cd-8f49-32bfa00bed7e@oss.qualcomm.com/ Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
- Mar 05, 2025
-
-
Miri Korenblit authored
iwlwifi is the driver of all Intel wifi devices since 2008. Since then, the hardware has changed a lot, but the firmware API has changed even more. The need to keep one driver that supports all those different APIs led us to introduce a new architecture circa 2012 which allowed us to keep the same interface to the hardware (DMAs, Tx queues, etc...) with a new layer to implement the mid-layer between mac80211 and the firmware. The first component is called the 'transport' and the latter is called 'operation_mode' a.k.a op_mode. In 2013 we took advantage of the new architecture to introduce iwlmvm which allowed us to implement the, then, new firmware API. This op_mode supports 7260 and up, those devices supports support at least VHT. Since then, wifi evolved and so did the firmware. It became much bigger and took a lot of functionality from the driver. It became increasingly hard to keep the same op_mode for the newest devices and we experienced frequent regressions on older devices. In order to avoid those regressions and keep the code maintainable, we decided it was about time to start a new op_mode. iwlmld is a new op_mode that supports BE200 or newer if the firmware being used is 97.ucode or newer. If the user has an older devices or BE200 with .96.ucode, iwlmvm will be loaded. Of course, this op_mode selection is seamless. All the features supported in iwlmvm are supported in iwlmld besides a few seldom used use cases: injection and Hotspot 2.0. Those are under work. A few points about the implementation: * iwlmld doesn't have any mutexes, it relies on the wiphy_lock * iwlmld is more "resource oriented": stations, links and interfaces are allocated and freed only after all the relevant flows are completed. * Firmware notifications' sizes are validated in a more structured way. We would love to see this new op_mode merged in 6.15. The firmware for this new driver (.97.ucode) is not yet publicly available but it'll be sent very soon. People eager to get an early version of this firmware can contact Emmanuel at: emmanuel.grumbach@intel.com I've listed the people who directly contributed code, but many others from various teams have contributed in other ways. Co-developed-by:
Avraham Stern <avraham.stern@intel.com> Signed-off-by:
Daniel Gabay <daniel.gabay@intel.com> Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com> Signed-off-by:
Yedidya Benshimol <yedidya.ben.shimol@intel.com> Signed-off-by:
Benjamin Berg <benjamin.berg@intel.com> Signed-off-by:
Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by:
Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://lore.kernel.org/linux-wireless/20250216094321.537988-1-miriam.rachel.korenblit@intel.com/ [fix Kconfig, fix api/phy.h includes, SPDX tag and coding style issues, duplicated includes per 0-day robot] Signed-off-by:
-
- Mar 04, 2025
-
-
Bob Copeland authored
Signed-off-by:Bob Copeland <me@bobcopeland.com>
-
Bob Copeland authored
-
