kernel/drivers/net/wireless, branch linux-6.9.y

wifi: iwlwifi: mvm: don't wake up rx_sync_waitq upon RFKILL

2024-07-25T07:53:42Z

commit e715c9302b1c6fae990b9898a80fac855549d1f0 upstream. 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: 4d08c0b3357c ("wifi: iwlwifi: mvm: handle BA session teardown in RF-kill") Signed-off-by: Emmanuel Grumbach Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20240703064027.be7a9dbeacde.I5586cb3ca8d6e44f79d819a48a0c22351ff720c9@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

wifi: iwlwifi: properly set WIPHY_FLAG_SUPPORTS_EXT_KEK_KCK

2024-07-25T07:53:39Z

[ Upstream commit 4ec17ce716bdaf680288ce680b4621b52483cc96 ] The WIPHY_FLAG_SUPPORTS_EXT_KEK_KCK should be set based on the WOWLAN_KEK_KCK_MATERIAL command version. Currently, the command version in the firmware has advanced to 4, which prevents the flag from being set correctly, fix that. Signed-off-by: Daniel Gabay Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20240703064026.a0f162108575.If1a9785727d2a1b0197a396680965df1b53d4096@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin

wifi: iwlwifi: mvm: Fix scan abort handling with HW rfkill

2024-07-25T07:53:22Z

[ Upstream commit e6dd2936ce7ce94a1915b799f8af8193ec628e87 ] When HW rfkill is toggled to disable the RF, the flow to stop scan is called. When trying to send the command to abort the scan, since HW rfkill is toggled, the command is not sent due to rfkill being asserted, and -ERFKILL is returned from iwl_trans_send_cmd(), but this is silently ignored in iwl_mvm_send_cmd() and thus the scan abort flow continues to wait for scan complete notification and fails. Since it fails, the UID to type mapping is not cleared, and thus a warning is later fired when trying to stop the interface. To fix this, modify the UMAC scan abort flow to force sending the scan abort command even when in rfkill, so stop the FW from accessing the radio etc. Signed-off-by: Ilan Peer Signed-off-by: Miri Korenblit Link: https://msgid.link/20240513132416.8cbe2f8c1a97.Iffe235c12a919dafec88eef399eb1f7bae2c5bdb@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin

wifi: iwlwifi: mvm: properly set 6 GHz channel direct probe option

2024-07-25T07:53:21Z

[ Upstream commit 989830d1cf16bd149bf0690d889a9caef95fb5b1 ] Ensure that the 6 GHz channel is configured with a valid direct BSSID, avoiding any invalid or multicast BSSID addresses. Signed-off-by: Ayala Beker Reviewed-by: Ilan Peer Signed-off-by: Miri Korenblit Link: https://msgid.link/20240513132416.91a631a0fe60.I2ea2616af9b8a2eaf959b156c69cf65a2f1204d4@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin

wifi: iwlwifi: mvm: handle BA session teardown in RF-kill

2024-07-25T07:53:21Z

[ Upstream commit 4d08c0b3357cba0aeffaf3abc62cae0c154f2816 ] When entering RF-kill, mac80211 tears down BA sessions, but due to RF-kill the commands aren't sent to the device. As a result, there can be frames pending on the reorder buffer or perhaps even received while doing so, leading to warnings. Avoid the warnings by doing the BA session teardown normally even in RF-kill, which also requires queue sync. Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://msgid.link/20240513132416.0762cd80fb3d.I43c5877f3b546159b2db4f36d6d956b333c41cf0@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin

wifi: iwlwifi: mvm: Handle BIGTK cipher in kek_kck cmd

2024-07-25T07:53:21Z

[ Upstream commit 08b16d1b5997dc378533318e2a9cd73c7a898284 ] The BIGTK cipher field was added to the kek_kck_material_cmd but wasn't assigned. Fix that by differentiating between the IGTK/BIGTK keys and assign the ciphers fields accordingly. Signed-off-by: Yedidya Benshimol Signed-off-by: Miri Korenblit Link: https://msgid.link/20240513132416.7fd0b22b7267.Ie9b581652b74bd7806980364d59e1b2e78e682c0@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin

wifi: iwlwifi: mvm: remove stale STA link data during restart

2024-07-25T07:53:21Z

[ Upstream commit cc3ba78f202de9752aceb16342ab62bdfbffac7e ] If pre-recovery mac80211 tried to disable a link but this disablement failed, then there might be a mismatch between mac80211 assuming the link has been disabled and the driver still having the data around. During recover itself, that is not a problem, but should the link be activated again at a later point, iwlwifi will refuse the activation as it detects the inconsistent state. Solve this corner-case by iterating the station in the restart cleanup handler. Signed-off-by: Benjamin Berg Signed-off-by: Miri Korenblit Link: https://msgid.link/20240513132416.d2fd60338055.I840d4fdce5fd49fe69896d928b071067e3730259@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin

wifi: iwlwifi: mvm: d3: fix WoWLAN command version lookup

2024-07-25T07:53:21Z

[ Upstream commit b7ffca99313d856f7d1cc89038d9061b128e8e97 ] After moving from commands to notificaitons in the d3 resume flow, removing the WOWLAN_GET_STATUSES and REPLY_OFFLOADS_QUERY_CMD causes the return of the default value when looking up their version. Returning zero here results in the driver sending the not supported NON_QOS_TX_COUNTER_CMD. Signed-off-by: Yedidya Benshimol Reviewed-by: Gregory Greenman Signed-off-by: Miri Korenblit Link: https://msgid.link/20240510170500.8cabfd580614.If3a0db9851f56041f8f5360959354abd5379224a@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin

wifi: wilc1000: fix ies_len type in connect path

2024-07-11T10:51:12Z

[ Upstream commit 39ab8fff623053a50951b659e5f6b72343d7d78c ] Commit 205c50306acf ("wifi: wilc1000: fix RCU usage in connect path") made sure that the IEs data was manipulated under the relevant RCU section. Unfortunately, while doing so, the commit brought a faulty implicit cast from int to u8 on the ies_len variable, making the parsing fail to be performed correctly if the IEs block is larger than 255 bytes. This failure can be observed with Access Points appending a lot of IEs TLVs in their beacon frames (reproduced with a Pixel phone acting as an Access Point, which brough 273 bytes of IE data in my testing environment). Fix IEs parsing by removing this undesired implicit cast. Fixes: 205c50306acf ("wifi: wilc1000: fix RCU usage in connect path") Signed-off-by: Jozef Hopko Signed-off-by: Alexis Lothoré Acked-by: Ajay Singh Signed-off-by: Kalle Valo Link: https://patch.msgid.link/20240701-wilc_fix_ies_data-v1-1-7486cbacf98a@bootlin.com Signed-off-by: Sasha Levin

wifi: mt76: mt7996: add sanity checks for background radar trigger

2024-07-11T10:51:02Z

[ Upstream commit ec55d8e7dfea92daff87f5c01689633f8c4e6a62 ] Check if background radar is enabled or not before manually triggering it, and also add more checks in radar detected event. Signed-off-by: StanleyYP Wang Signed-off-by: Shayne Chen Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin