summaryrefslogtreecommitdiff
path: root/drivers/net/wireless
AgeCommit message (Collapse)AuthorFilesLines
2024-12-12wifi: rtlwifi: fix memory leaks and invalid access at probe error pathThadeu Lima de Souza Cascardo1-5/+8
Deinitialize at reverse order when probe fails. When init_sw_vars fails, rtl_deinit_core should not be called, specially now that it destroys the rtl_wq workqueue. And call rtl_pci_deinit and deinit_sw_vars, otherwise, memory will be leaked. Remove pci_set_drvdata call as it will already be cleaned up by the core driver code and could lead to memory leaks too. cf. commit 8d450935ae7f ("wireless: rtlwifi: remove unnecessary pci_set_drvdata()") and commit 3d86b93064c7 ("rtlwifi: Fix PCI probe error path orphaned memory"). Fixes: 0c8173385e54 ("rtl8192ce: Add new driver") Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241206173713.3222187-4-cascardo@igalia.com
2024-12-12wifi: rtlwifi: destroy workqueue at rtl_deinit_coreThadeu Lima de Souza Cascardo3-7/+6
rtl_wq is allocated at rtl_init_core, so it makes more sense to destroy it at rtl_deinit_core. In the case of USB, where _rtl_usb_init does not require anything to be undone, that is fine. But for PCI, rtl_pci_init, which is called after rtl_init_core, needs to deallocate data, but only if it has been called. That means that destroying the workqueue needs to be done whether rtl_pci_init has been called or not. And since rtl_pci_deinit was doing it, it has to be moved out of there. It makes more sense to move it to rtl_deinit_core and have it done in both cases, USB and PCI. Since this is a requirement for a followup memory leak fix, mark this as fixing such memory leak. Fixes: 0c8173385e54 ("rtl8192ce: Add new driver") Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241206173713.3222187-3-cascardo@igalia.com
2024-12-12wifi: rtlwifi: remove unused check_buddy_privThadeu Lima de Souza Cascardo4-64/+0
Commit 2461c7d60f9f ("rtlwifi: Update header file") introduced a global list of private data structures. Later on, commit 26634c4b1868 ("rtlwifi Modify existing bits to match vendor version 2013.02.07") started adding the private data to that list at probe time and added a hook, check_buddy_priv to find the private data from a similar device. However, that function was never used. Besides, though there is a lock for that list, it is never used. And when the probe fails, the private data is never removed from the list. This would cause a second probe to access freed memory. Remove the unused hook, structures and members, which will prevent the potential race condition on the list and its corruption during a second probe when probe fails. Fixes: 26634c4b1868 ("rtlwifi Modify existing bits to match vendor version 2013.02.07") Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241206173713.3222187-2-cascardo@igalia.com
2024-12-12wifi: rtw89: 8922a: update format of RFK pre-notify H2C command v2Chih-Kang Chang3-10/+31
The RFK pre-notify H2C command is to tell firmware the channels driver is using. Since the format is changed after 0.35.49.0, update it accordingly. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241206055716.18598-8-pkshih@realtek.com
2024-12-12wifi: rtw89: regd: update regulatory map to R68-R51Zong-Zhe Yang1-27/+30
Sync Realtek Channel Plan R68 and Realtek Regulatory R51. Configure 6 GHz field of Realtek regd for the following countries. BO, DO, EG, LS, MZ, NG, OM, ZW, PK, PH, TH, KM, CG, CD, GE, GI, GU, LR, MH, FM, MP, PW, MF, SX, SZ, TZ, VI Besides, add entries for the following countries. CU, SY, SD Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241206055716.18598-7-pkshih@realtek.com
2024-12-12wifi: rtw89: 8852c: disable ER SU when 4x HE-LTF and 0.8 GI capability differKuan-Chung Chen2-5/+29
Since hardware only has single one register for HE-LTF setting, to prevent interoperability issues, 8852CE disables ER SU when the AP can handle SU/MU with 4x HE-LTF and 0.8 GI, but does not support ER SU with the same settings. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241206055716.18598-6-pkshih@realtek.com
2024-12-12wifi: rtw89: disable firmware training HE GI and LTFKuan-Chung Chen2-8/+26
Given the performance trade-off associated with firmware training HE GI/LTF, especially in high attenuation environments, we have decided to utilize a constant value instead. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241206055716.18598-5-pkshih@realtek.com
2024-12-12wifi: rtw89: ps: update data for firmware and settings for hardware ↵Eric Huang7-1/+118
before/after PS For MLO supported IC, send H2C command to firmware before PS with link information for each PHY for MLO to work properly. And re-init hardware settings regarding to RX descriptor information after PS. Signed-off-by: Eric Huang <echuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241206055716.18598-4-pkshih@realtek.com
2024-12-12wifi: rtw89: ps: refactor channel info to firmware before entering PSPing-Ke Shih3-11/+30
In PS mode, firmware needs hardware parameters related to channel info to configure hardware itself. Before entering PS, driver prepares these info to firmware via firmware H2C command. Since firmware only consider PS for single one vif, change the argument of entry function to rtwvif, and only consider first link for this old H2C command that only support legacy. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241206055716.18598-3-pkshih@realtek.com
2024-12-12wifi: rtw89: ps: refactor PS flow to support MLOPing-Ke Shih4-40/+29
Firmware can only support PS on single one VIF operating in station mode, so argument of PS entry rtw89_enter_lps() should be rtwvif insetad of rtwvif_link. To enter PS under MLO, for each rtwvif, driver sends H2C command to tell firmware which mac_id will enter PS one by one, and afterward asks firmware to enter deep PS. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241206055716.18598-2-pkshih@realtek.com
2024-12-11wifi: ath12k: Off by one in ath12k_wmi_process_csa_switch_count_event()Dan Carpenter1-1/+1
The ahvif->vif->link_conf[] array has IEEE80211_MLD_MAX_NUM_LINKS elements so this should be >= instead of > to avoid an out of bounds access. Fixes: 3952657848c0 ("wifi: ath12k: Use mac80211 vif's link_conf instead of bss_conf") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Acked-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/755becb1-819b-484d-8fac-9a2db53ced1b@stanley.mountain Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2024-12-11wifi: ath12k: fix leaking michael_mic for non-primary linksBaochen Qiang1-0/+1
In ath12k_dp_rx_peer_frag_setup(), commit ea4192553850 ("wifi: ath12k: add primary link for data path operations") checks whether a link is the primary link, and returns directly if it isn't. In ML scenario where we have non-primary links created, this results in leaking the michael_mic info since it is allocated by default but could never be freed for a non-primary link. Note that we can not move the might-sleep allocation after primary link check since there we are in atomic context (due to spin lock). So keep the default allocation, and then free it before return to fix this issue. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0-03427-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.15378.4 Fixes: ea4192553850 ("wifi: ath12k: add primary link for data path operations") Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Acked-by: Kalle Valo <kvalo@kernel.org> Acked-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Link: https://patch.msgid.link/20241206054552.177424-1-quic_bqiang@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2024-12-11Merge tag 'wireless-2024-12-10' of ↵Jakub Kicinski1-1/+1
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless Johannes Berg says: ==================== A small set of fixes: - avoid CSA warnings during link removal (by changing link bitmap after remove) - fix # of spatial streams initialisation - fix queues getting stuck in some CSA cases and resume failures - fix interface address when switching monitor mode - fix MBSS change flags 32-bit stack corruption - more UBSAN __counted_by "fixes" ... - fix link ID netlink validation * tag 'wireless-2024-12-10' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: wifi: cfg80211: sme: init n_channels before channels[] access wifi: mac80211: fix station NSS capability initialization order wifi: mac80211: fix vif addr when switching from monitor to station wifi: mac80211: fix a queue stall in certain cases of CSA wifi: mac80211: wake the queues in case of failure in resume wifi: cfg80211: clear link ID from bitmap during link delete after clean up wifi: mac80211: init cnt before accessing elem in ieee80211_copy_mbssid_beacon wifi: mac80211: fix mbss changed flags corruption on 32 bit systems wifi: nl80211: fix NL80211_ATTR_MLO_LINK_ID off-by-one ==================== Link: https://patch.msgid.link/20241210130145.28618-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-12-09Merge tag 'ath-next-20241209' of ↵Kalle Valo54-714/+4020
git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath ath.git patches for v6.14 This development cycle featured multiple patchsets to ath12k to support the new 802.11be MLO feature, although the feature is still incomplete. Also in ath12k, there were other feature patches. In ath11k, support was added for QCA6698AQ. And there was the usual set of bug fixes and cleanups across most drivers, notable being the addition of "noinline_for_stack" to some functions to avoid "stack frame size" warnings when compiling with clang.
2024-12-09wifi: mwifiex: decrease timeout waiting for host sleep from 10s to 5sPin-yen Lin1-1/+1
In commit 52250cbee7f6 ("mwifiex: use timeout variant for wait_event_interruptible") it was noted that sometimes we seemed to miss the signal that our host sleep settings took effect. A 10 second timeout was added to the code to make sure we didn't hang forever waiting. It appears that this problem still exists and we hit the timeout sometimes for Chromebooks in the field. Recently on ChromeOS we've started setting the DPM watchdog to trip if full system suspend takes over 10 seconds. Given the timeout in the original patch, obviously we're hitting the DPM watchdog before mwifiex gets a chance to timeout. While we could increase the DPM watchdog in ChromeOS to avoid this problem, it's probably better to simply decrease the timeout. Any time we're waiting several seconds for the firmware to respond it's likely that the firmware won't ever respond. With that in mind, decrease the timeout in mwifiex from 10 seconds to 5 seconds. Suggested-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Pin-yen Lin <treapking@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Acked-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241127105709.4014302-1-treapking@chromium.org
2024-12-09wifi: brcmfmac: fix brcmf_vif_clear_mgmt_ies when stopping APRenjaya Raga Zenta1-1/+5
This removes the following error log when stopping AP: ieee80211 phy0: brcmf_vif_set_mgmt_ie: vndr ie set error : -52 It happened if: 1) previously wlan interface was in station mode (wpa_supplicant) and connected to a hotspot 2) then started AP mode (hostapd) 3) and then stopped AP mode. The error happened when it tried to clear BRCMF_VNDR_IE_PRBREQ_FLAG. This flag is not set in `brcmf_config_ap_mgmt_ie`, but BRCMF_VNDR_IE_ASSOCRSP_FLAG is set instead. Signed-off-by: Renjaya Raga Zenta <ragazenta@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241121-brcmfmac-v1-1-02fc3fb427c2@gmail.com
2024-12-09wifi: wlcore: testmode: Constify strutc nla_policyChristophe JAILLET1-1/+1
'struct nla_policy' is not modified in this driver. Constifying this structure moves some data to a read-only section, so increase overall security, especially when the structure holds some function pointers. On a x86_64, with allmodconfig: Before: ====== text data bss dec hex filename 5062 528 0 5590 15d6 drivers/net/wireless/ti/wlcore/testmode.o After: ===== text data bss dec hex filename 5178 404 0 5582 15ce drivers/net/wireless/ti/wlcore/testmode.o Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/78810e3ebb74ddbd3a4538f182bf1143b89baba7.1731332414.git.christophe.jaillet@wanadoo.fr
2024-12-09wifi: brcmfmac: fix scatter-gather handling by detecting end of sg listNorbert van Bolhuis1-0/+5
The scatter-gather handling uses a pre-allocated list (with nents entries). If the driver runs out of sg entries it will result in an oops. Let's detect this instead and make the SDIO block transfer fail. Signed-off-by: Norbert van Bolhuis <nvbolhuis@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241108125609.107016-1-nvbolhuis@gmail.com
2024-12-06wifi: ath12k: introduce mlo_capable flag for device groupKarthikeyan Periyasamy4-5/+29
Currently, during mac80211 allocate and register single device is considered for the registration. But, in future, during multi device group abstraction is introduced, all the devices has to be combined together as a single abstraction and then hardware should be allocated. All the devices in the group should be combined together only if it supports inter device mlo capability. The decision of whether to combine the devices or not can be based on the mlo capability flag in ath12k_hw_group. By default, mlo_capable flag in the group would be set as false. During QMI PHY capability exchange, only when we have more than one chip in the group or if one chip, then that chip supports inter MLO, then mlo_capable flag in the group will be enabled. Add changes to introduce mlo_capable flag for device group and refactor ath12k_mac_hw_allocate() api based on device group (ag) rather than device (ab). 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 <quic_periyasa@quicinc.com> Signed-off-by: Harshitha Prem <quic_hprem@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20241204163216.433795-8-kvalo@kernel.org Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2024-12-06wifi: ath12k: send QMI host capability after device group is readyKarthikeyan Periyasamy3-5/+134
QMI host capability has the information regarding MLO parameters such as device_id, MLO capability, group id and the information of each devices involved in the group and sent immediately on QMI server arrive event. Currently, only one device is involved in the group and hence, single device information is sent as part of MLO capability of host. But, in future when multi device group abstraction is introduced, host should send all the device information involved in the group as part of QMI MLO host capability rather than single device. Hence, sending QMI host capability immediately on server arrive of a device might not be ideal for multi device group abstraction as the details of other devices in the group would not be available. Hence, once QMI server arrive event is received, request for QMI PHY capabilities of device, and defer the host capability send for that device. After QMI PHY capability is received for all the devices in the group trigger the host capability event for the deferred devices in the group. Hence, add changes to defer the QMI host capability event until the device group is ready and then resume the QMI exchange for all the device with host capabilities. 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 <quic_periyasa@quicinc.com> Signed-off-by: Harshitha Prem <quic_hprem@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20241204163216.433795-7-kvalo@kernel.org Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2024-12-06wifi: ath12k: move struct ath12k_hw from per device to groupKarthikeyan Periyasamy6-82/+115
Currently, hardware abstractions (ah) of different radio bands are tightly coupled to a single device (ab). But, with hardware device group abstraction (ag), multiple radios across different devices in a group can form different combinations of hardware abstractions (ah) within the group. Hence, the mapping between ah to ab can be removed and instead it can be mapped with struct ath12k_hw_group (ag). Current mapping between struct ath12k_hw (ah), struct ath12k_base (ab) and struct ath12k_hw_group (ag): +------------------------------------------------+ | +-------------------------------------+ | | | +---------------+ +---------------+ | | | | |ath12k_hw (ah) | |ath12k_hw (ah) | | | | | +---------------+ +---------------+ | | | | | | | | +-----------+ | +-----------+ | | | | | ar (2GHz) | | | ar (5GHz) | | | | | +-----------+ | +-----------+ | | | | Dual band device-1 (ab) | | | +-------------------------------------+ | | ath12k_hw_group (ag) based on group id | +------------------------------------------------+ After hardware device group abstraction moving ah array out of ab to ag: +----------------------------------------------+ | +---------------+ +---------------+ | | |ath12k_hw (ah) | |ath12k_hw (ah) | | | +---------------+ +---------------+ | | +-------------------------------------+ | | | +-----------+ +-----------+ | | | | | ar (2GHz) | | ar (5GHz) | | | | | +-----------+ +-----------+ | | | | Dual band device-1 (ab) | | | +-------------------------------------+ | | ath12k_hw_group (ag) based on group id | +----------------------------------------------+ This decoupling of struct ath12k_hw (ah) from struct ath12k_base (ab) and mapping it to struct ath12k_hw_group (ag) will help in forming different combinations of multi-link devices. 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 <quic_periyasa@quicinc.com> Signed-off-by: Harshitha Prem <quic_hprem@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20241204163216.433795-6-kvalo@kernel.org Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2024-12-06wifi: ath12k: refactor core start based on hardware groupKarthikeyan Periyasamy3-51/+170
Currently, mac allocate/register and core_pdev_create are initiated immediately when QMI firmware ready event is received for a particular device. With hardware device group abstraction, QMI firmware ready event can be received simultaneously for different devices in the group and so, it should not be registered immediately rather it has to be deferred until all devices in the group has received QMI firmware ready. To handle this, refactor the code of core start to have registering within ath12k_core_hw_group_start() and unregistering in ath12k_core_hw_group_stop(). 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 <quic_periyasa@quicinc.com> Co-developed-by: Harshitha Prem <quic_hprem@quicinc.com> Signed-off-by: Harshitha Prem <quic_hprem@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20241204163216.433795-5-kvalo@kernel.org Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2024-12-06wifi: ath12k: introduce device group abstractionKarthikeyan Periyasamy3-13/+236
Currently, single device is probed, and once firmware is ready, the device is registered to mac80211. For Multi-Link Operation, different bands of different devices or same device are part of a single wiphy and for this, hardware device group abstraction is needed. Hardware device group abstraction - when there are multiple devices (with single radio or dual radio) that are connected by any means of interface for communicating between them, then these devices can be combined together as a single group using a group id to form a group abstraction and register to mac80211. The grouping information of multiple devices would be based on device tree during device probe (will be implemented in future patches). If no such information is available, then a single device will be part of group abstraction and registered to mac80211, else multiple devices advertised in device tree are combined and then registered to mac80211. For device group abstraction, a base structure ath12k_hw_group (ag) and the helpers are implemented. These helpers are used during device probe and mapping the group to the devices involved. An illustration of how multiple devices might be combined together in future based on group id: +------------------------------------------------------------------------+ | +-------------------------------------+ +-------------------+ | | | +-----------+ | | +-----------+ | | +-----------+ | | | | | ar (2GHz) | | | | ar (5GHz) | | | | ar (6GHz) | | | | | +-----------+ | | +-----------+ | | +-----------+ | | | | ath12k_base (ab) | | ath12k_base (ab) | | | | (Dual band device) | | | | | +-------------------------------------+ +-------------------+ | | ath12k_hw_group (ag) based on group id | +------------------------------------------------------------------------+ In the above representation, two devices are combined into single group based on group id. Add base code changes where single device would be part of a group with an invalid group id forming an group abstraction. Multi device grouping will be introduced in future. 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 <quic_periyasa@quicinc.com> Co-developed-by: Harshitha Prem <quic_hprem@quicinc.com> Signed-off-by: Harshitha Prem <quic_hprem@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20241204163216.433795-4-kvalo@kernel.org Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2024-12-06wifi: ath12k: rename mlo_capable_flags to single_chip_mlo_suppAditya Kumar Singh3-30/+8
At present, the mlo_capable_flags in ath12k_base is used to indicate whether the chip supports inter (QCN9274) or intra (WCN7850) chip MLO. However, it’s possible that the chip supports neither, especially with older firmware versions. Additionally, if intra chip MLO is not supported, inter chip MLO will also be non-functional. Therefore, having two separate flags for this is unnecessary. Therefore, rename this flag to single_chip_mlo_supp. At the same time convert it into a bool data type. Also, get rid of the enums defined earlier. For the QCN9274 family of chipsets, this will be set only when firmware advertises the support during the QMI exchange. For the WCN7850 family of chipsets, since the event is not supported, assumption is made that single chip MLO is supported. 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 <quic_adisi@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20241204163216.433795-3-kvalo@kernel.org Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2024-12-06wifi: ath12k: move ATH12K_FLAG_REGISTERED handling to ath12k_mac_register()Karthikeyan Periyasamy2-3/+5
When hardware device group abstraction is introduced, a group abstraction is registered to mac80211 rather than a particular single device. So we cannot set the device registered when the QMI firmware ready event is received, only after all the devices in group have received the event. To do that set and unset ATH12K_FLAG_REGISTERED flag inside ath12k_mac_register() and ath12k_mac_unregister() respectively. 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 <quic_periyasa@quicinc.com> Signed-off-by: Harshitha Prem <quic_hprem@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20241204163216.433795-2-kvalo@kernel.org Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2024-12-05wifi: rtw89: add crystal_cap check to avoid setting as overflow valueChih-Kang Chang2-6/+7
In the original flow, the crystal_cap might be calculated as a negative value and set as an overflow value. Therefore, we added a check to limit the calculated crystal_cap value. Additionally, we shrank the crystal_cap adjustment according to specific CFO. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241128055433.11851-7-pkshih@realtek.com
2024-12-05wifi: rtw89: refine link handling for link_sta_rc_updateZong-Zhe Yang3-11/+16
The original handling will iterate all active links under the given sta and apply the changes to each. Now, stack tweaks ops from sta_rc_update to link_sta_rc_update, which means targeting a given link. Then, our link iteration looks redundant. So, refine it to apply the changes to the link directly. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241128055433.11851-6-pkshih@realtek.com
2024-12-05wifi: rtw89: 8922a: use RSSI from PHY report in RX descriptorChih-Kang Chang14-6/+127
The PPDU status of probe response will fail to parse the IE due to being filtered by the to_self check. Therefore, we parse RSSI from PHY report in RX descriptor. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241128055433.11851-5-pkshih@realtek.com
2024-12-05wifi: rtw89: 8852bt: add beacon filter and CQM supportPo-Hao Huang1-0/+1
Declare beacon filter and connection monitor for 8852BT. This offloads connection monitor mechanism to firmware, and this is required for the MCC feature. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241128055433.11851-4-pkshih@realtek.com
2024-12-05wifi: rtw89: 8852b: add beacon filter and CQM supportPo-Hao Huang1-0/+1
Declare beacon filter and connection monitor for 8852B. This offloads connection monitor mechanism to firmware, and this is required for the MCC feature. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241128055433.11851-3-pkshih@realtek.com
2024-12-05wifi: rtw89: 8922a: Extend channel info field length for scanPo-Hao Huang5-21/+71
Extend the bitfield for duration in channel info to 16 bits. Update the related format in H2C and C2H, then increase firmware format sequence to 3. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241128055433.11851-2-pkshih@realtek.com
2024-12-04wifi: mac80211_hwsim: add 6 GHz EHT Mesh capabilitiesAditya Kumar Singh1-0/+39
To facilitate testing of mesh EHT 320 MHz, add support for advertising this capability. Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Link: https://patch.msgid.link/20241119-mesh_320mhz_support-v1-2-f9463338d584@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-12-04wifi: mac80211: get tx power per linkRameshkumar Sundaram4-3/+4
ML interfaces can have multiple affiliated links to it and hence there is a need to report tx power of specified link rather deflink. Add changes to report tx power of requested link from mac80211, also pass link id as an argument in get_tx_power op so that supported drivers can use it to report link's tx power. Co-developed-by: Aaradhana Sahu <quic_aarasahu@quicinc.com> Signed-off-by: Aaradhana Sahu <quic_aarasahu@quicinc.com> Signed-off-by: Rameshkumar Sundaram <quic_ramess@quicinc.com> Link: https://patch.msgid.link/20241125083217.216095-3-quic_ramess@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-12-04wifi: cfg80211: send MLO links tx power info in GET_INTERFACERameshkumar Sundaram5-4/+5
Currently, TX power is reported on interface/wdev level as part of NL80211_CMD_GET_INTERFACE. With MLO, Multiple links can be part of an interface/wdev and hence its necessary to report the TX power of each link. Add support to send tx power for all valid links of an MLD as part of NL80211_CMD_GET_INTERFACE request. As far as userspace is concerned, there is no behavioral change for Non-ML Interfaces. For ML interfaces, userspace should fetch TX power that is nested inside NL80211_ATTR_MLO_LINKS, similar to how channel info(NL80211_ATTR_WIPHY_FREQ) is fetched. Co-developed-by: Aaradhana Sahu <quic_aarasahu@quicinc.com> Signed-off-by: Aaradhana Sahu <quic_aarasahu@quicinc.com> Signed-off-by: Rameshkumar Sundaram <quic_ramess@quicinc.com> Link: https://patch.msgid.link/20241125083217.216095-2-quic_ramess@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-12-04wifi: iwlwifi: mvm: Replace spaces for tabs in iwl_mvm_vendor_events_idxJuan José Arboleda1-3/+3
This patch replaces spaces with tabs in the affected source files to adhere to the Linux kernel coding style guidelines. This change is purely stylistic and do not affect the functionality of the code. Signed-off-by: Juan José Arboleda <soyjuanarbol@gmail.com> Link: https://patch.msgid.link/715c74c74b336bed81e92e1336bd1a6ddb7b90ff.1724103043.git.soyjuanarbol@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-12-03wifi: mac80211: fix a queue stall in certain cases of CSAEmmanuel Grumbach1-1/+1
If we got an unprotected action frame with CSA and then we heard the beacon with the CSA IE, we'll block the queues with the CSA reason twice. Since this reason is refcounted, we won't wake up the queues since we wake them up only once and the ref count will never reach 0. This led to blocked queues that prevented any activity (even disconnection wouldn't reset the queue state and the only way to recover would be to reload the kernel module. Fix this by not refcounting the CSA reason. It becomes now pointless to maintain the csa_blocked_queues state. Remove it. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Fixes: 414e090bc41d ("wifi: mac80211: restrict public action ECSA frame handling") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219447 Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20241119173108.5ea90828c2cc.I4f89e58572fb71ae48e47a81e74595cac410fbac@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-12-02module: Convert symbol namespace to string literalPeter Zijlstra10-10/+10
Clean up the existing export namespace code along the same lines of commit 33def8498fdd ("treewide: Convert macro and uses of __section(foo) to __section("foo")") and for the same reason, it is not desired for the namespace argument to be a macro expansion itself. Scripted using git grep -l -e MODULE_IMPORT_NS -e EXPORT_SYMBOL_NS | while read file; do awk -i inplace ' /^#define EXPORT_SYMBOL_NS/ { gsub(/__stringify\(ns\)/, "ns"); print; next; } /^#define MODULE_IMPORT_NS/ { gsub(/__stringify\(ns\)/, "ns"); print; next; } /MODULE_IMPORT_NS/ { $0 = gensub(/MODULE_IMPORT_NS\(([^)]*)\)/, "MODULE_IMPORT_NS(\"\\1\")", "g"); } /EXPORT_SYMBOL_NS/ { if ($0 ~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+),/) { if ($0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/ && $0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(\)/ && $0 !~ /^my/) { getline line; gsub(/[[:space:]]*\\$/, ""); gsub(/[[:space:]]/, "", line); $0 = $0 " " line; } $0 = gensub(/(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/, "\\1(\\2, \"\\3\")", "g"); } } { print }' $file; done Requested-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://mail.google.com/mail/u/2/#inbox/FMfcgzQXKWgMmjdFwwdsfgxzKpVHWPlc Acked-by: Greg KH <gregkh@linuxfoundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-11-30wifi: ath12k: introduce QMI firmware ready flagKarthikeyan Periyasamy3-4/+11
When hardware device group abstraction is introduced, the QMI firmware ready event of different devices in a group can be received simultaneously. To indicate the firmware ready event is completed for a particular device in a group set a flag (ATH12K_FLAG_QMI_FW_READY_COMPLETE). This helps the upcoming hardware recovery implementation for hardware device group abstraction. 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 <quic_periyasa@quicinc.com> Signed-off-by: Harshitha Prem <quic_hprem@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20241128165026.2618331-5-kvalo@kernel.org
2024-11-30wifi: ath12k: add ath12k_get_num_hw()Karthikeyan Periyasamy3-8/+13
Currently, one or more struct ath12k_hw is part of device (struct ath12k_base) but in future, ath12k_hw would be part of device group (struct ath12k_hw_group). Hence, num_hw under device would be moved to device group. To facilitate above transition, add helper ath12k_get_num_hw() to get the number of radios per device. In future, this helper will return the number of radios in a device group. 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 <quic_periyasa@quicinc.com> Signed-off-by: Harshitha Prem <quic_hprem@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20241128165026.2618331-4-kvalo@kernel.org
2024-11-30wifi: ath12k: add ath12k_ab_to_ah() and ath12k_ab_set_ah()Karthikeyan Periyasamy3-14/+28
Currently, one or more ath12k_hw is part of a device (struct ath12k_base) but in future, it would be part of device group abstraction (struct ath12k_hw_group), i.e., when multiple radios (ar) across different devices can be combined together in a device group (struct ath12k_hw_group). In order to facilitate the above transition, introduce helpers ath12k_ab_to_ah() and ath12k_ab_set_ah() to get and set values of ath12k_hw respectively. 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 <quic_periyasa@quicinc.com> Signed-off-by: Harshitha Prem <quic_hprem@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20241128165026.2618331-3-kvalo@kernel.org
2024-11-30wifi: ath12k: Refactor core startupKarthikeyan Periyasamy4-33/+50
In the upcoming hardware device group abstraction radios across different devices can be grouped together to support multi-link operation and register as a device group to mac80211. Currently, ath12k_mac_allocate() and ath12k_mac_register() are part of ath12k_core_start() and ath12k_core_pdev_create() respectively and are based on per device (struct ath12k_base). These APIs can be decoupled and moved out to ath12k_core_qmi_firmware_ready() itself. This refactor is helpful for device group abstraction when mac80211 allocate and register will be changed from per device (struct ath12k_base) to per device group (struct ath12k_hw_group). 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 <quic_periyasa@quicinc.com> Signed-off-by: Harshitha Prem <quic_hprem@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20241128165026.2618331-2-kvalo@kernel.org
2024-11-29wifi: ath12k: ath12k_mac_op_sta_rc_update(): use mac80211 provided link idKalle Valo1-13/+9
There's a todo comment to use mac80211 provided link id. As mac80211 now provides it use it in ath12k and remove the comment. 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: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20241126171139.2350704-11-kvalo@kernel.org
2024-11-29wifi: ath12k: ath12k_mac_op_set_key(): fix uninitialized symbol 'ret'Kalle Valo1-25/+32
Dan reported that in some cases the ret variable could be uninitialized. Fix that by removing the out label entirely and returning zero explicitly on succesful cases. Also remove the unnecessary else branches to follow more the style used in ath12k and now it's easier to see the error handling. No functional changes. 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 Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/all/7e7afd00-ad84-4744-8d94-416bab7e7dd9@stanley.mountain/ Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20241126171139.2350704-10-kvalo@kernel.org
2024-11-29wifi: ath12k: defer vdev creation for MLORameshkumar Sundaram1-6/+1
Currently for single radio devices (ah->num_radio == 1) ath12k_mac_op_add_interface() creates vdev and later hw scan and assign_vif_chanctx uses the same. For MLO, vdev create request should carry ML address which will not be known during ath12k_mac_op_add_interface() as vif will be marked as ML only after links are added to it. If hw scan is requested, the vdev will be deleted post hw scan and subsequent assign_vif_chanctx call will create new vdev with ML address. But in certain cases assign_vif_chanctx could be called without any prior hw scan request and reusing the previously created vdev causes a non-ML vdev to be used for an ML vif and firmware operates the vdev in non-ML mode. Fix this by deferring vdev creation for interface until hw scan or assign_vif_chanctx request is received from mac80211. 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: Rameshkumar Sundaram <quic_ramess@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20241126171139.2350704-9-kvalo@kernel.org
2024-11-29wifi: ath12k: ath12k_bss_assoc(): MLO supportAditya Kumar Singh1-8/+20
Currently, the ath12k_bss_assoc() function handles only deflink station connections. To support multi-link station connections, make the necessary changes to retrieve the required information from the link-level members. 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 <quic_adisi@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20241126171139.2350704-8-kvalo@kernel.org
2024-11-29wifi: ath12k: do not return invalid link id for scan linkSriram R3-18/+56
When a scan request is received, driver selects a link id for which the arvif can be mapped. Same link is also used for getting the link conf address. Currently, we return 0 as link id for a non ML vif, which is correct since that is the default link id. Also when any of the link vif is active and the scan request is for a channel in the active link we return its link id. But, when we don't hit both of the above cases (i.e not a ML vif or no active link vif for the channel is present) we currently return 0 as the link id. Bu the problemis that this might not work out always, eg., when only one link (eg. linkid = 1) is added to vif, then we won't find any link conf for link id 0 in the vif resulting in scan failure. During AP bringup, such scan failure causes bringup issues. Hence avoid sending link id 0 as default. Rather use a default link for scan and default link address for the same. This scan vdev will either be deleted if another scan is requested on same vif or when AP is broughtup on same link or during interface cleanup. 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 <quic_srirrama@quicinc.com> Signed-off-by: Rameshkumar Sundaram <quic_ramess@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20241126171139.2350704-7-kvalo@kernel.org
2024-11-29wifi: ath12k: ath12k_mac_station_add(): fix potential rx_stats leakRameshkumar Sundaram1-0/+2
If peer creation fails ar->rx_stats needs to be freed in error handling. 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: Rameshkumar Sundaram <quic_ramess@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20241126171139.2350704-6-kvalo@kernel.org
2024-11-29wifi: ath12k: ath12k_mac_op_ampdu_action(): MLO supportSriram R3-42/+76
Apply tid queue setup based on all link stations on receiving ampdu action params for an ML Station. Modify ath12k_get_ar_by_vif() to fetch ar based on link arvif inside ahvif. 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 <quic_srirrama@quicinc.com> Signed-off-by: Rameshkumar Sundaram <quic_ramess@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20241126171139.2350704-5-kvalo@kernel.org
2024-11-29wifi: ath12k: ath12k_mac_op_flush(): MLO supportSriram R1-4/+14
Currently when tx flush is requested for an vif only packets corresponding to deflink are flushed, with MLO multiple link arvif could be affiliated to the ML vif and packets corresponding to all of them should be flushed. 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 <quic_srirrama@quicinc.com> Co-developed-by: Maharaja Kennadyrajan <quic_mkenna@quicinc.com> Signed-off-by: Maharaja Kennadyrajan <quic_mkenna@quicinc.com> Signed-off-by: Rameshkumar Sundaram <quic_ramess@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20241126171139.2350704-4-kvalo@kernel.org
2024-11-29wifi: ath12k: ath12k_mac_op_tx(): MLO supportSriram R2-3/+137
For a frame transmission for an ML vif, mac80211 mentions transmit link id in the tx control info. Use it to convert the RA/TA to the corresponding link sta and link vif address before enqueueing the frame for transmission. For 802.3 data frames, always enqueue the frame on the primary (assoc) link id. Firmware does the link selection, builds 802.11 header and therefore the address translation too. Also ensure right link vif is used for WMI based management transmission and add comments to document when RCU read lock is held. 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 <quic_srirrama@quicinc.com> Co-developed-by: Rameshkumar Sundaram <quic_ramess@quicinc.com> Signed-off-by: Rameshkumar Sundaram <quic_ramess@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20241126171139.2350704-3-kvalo@kernel.org