blaster4385/linux-IllusionX/drivers/net/wireless/intel, branch v6.12.10

wifi: iwlwifi: mvm: Fix __counted_by usage in cfg80211_wowlan_nd_*

2025-01-09T12:33:52Z

commit cc0c53f4fac562efb3aca2bc493515e77642ae33 upstream. Both struct cfg80211_wowlan_nd_match and struct cfg80211_wowlan_nd_info pre-allocate space for channels and matches, but then may end up using fewer that the full allocation. Shrink the associated counter (n_channels and n_matches) after counting the results. This avoids compile-time (and run-time) warnings from __counted_by. (The counter member needs to be updated _before_ accessing the array index.) Seen with coming GCC 15: drivers/net/wireless/intel/iwlwifi/mvm/d3.c: In function 'iwl_mvm_query_set_freqs': drivers/net/wireless/intel/iwlwifi/mvm/d3.c:2877:66: warning: operation on 'match->n_channels' may be undefined [-Wsequence-point] 2877 | match->channels[match->n_channels++] = | ~~~~~~~~~~~~~~~~~^~ drivers/net/wireless/intel/iwlwifi/mvm/d3.c:2885:66: warning: operation on 'match->n_channels' may be undefined [-Wsequence-point] 2885 | match->channels[match->n_channels++] = | ~~~~~~~~~~~~~~~~~^~ drivers/net/wireless/intel/iwlwifi/mvm/d3.c: In function 'iwl_mvm_query_netdetect_reasons': drivers/net/wireless/intel/iwlwifi/mvm/d3.c:2982:58: warning: operation on 'net_detect->n_matches' may be undefined [-Wsequence-point] 2982 | net_detect->matches[net_detect->n_matches++] = match; | ~~~~~~~~~~~~~~~~~~~~~^~ Cc: stable@vger.kernel.org Fixes: aa4ec06c455d ("wifi: cfg80211: use __counted_by where appropriate") Signed-off-by: Kees Cook Reviewed-by: Gustavo A. R. Silva Link: https://patch.msgid.link/20240619211233.work.355-kees@kernel.org Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

wifi: iwlwifi: fix CRF name for Bz

2025-01-09T12:33:34Z

[ Upstream commit 0e8c52091633b354b12d0c29a27a22077584c111 ] We had BE201 hard coded. Look at the RF_ID and decide based on its value. Fixes: 6795a37161fb ("wifi: iwlwifi: Print a specific device name.") Signed-off-by: Emmanuel Grumbach Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20241212132940.b9eebda1ca60.I36791a134ed5e538e059418eb6520761da97b44c@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin

wifi: iwlwifi: be less noisy if the NIC is dead in S3

2025-01-02T09:34:20Z

commit 0572b7715ffd2cac20aac00333706f3094028180 upstream If the NIC is dead upon resume, try to catch the error earlier and exit earlier. We'll print less error messages and get to the same recovery path as before: reload the firmware. Signed-off-by: Emmanuel Grumbach Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20241028135215.3a18682261e5.I18f336a4537378a4c1a8537d7246cee1fc82b42c@changeid Signed-off-by: Johannes Berg Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219597 Signed-off-by: Sasha Levin

wifi: mac80211: fix a queue stall in certain cases of CSA

2024-12-19T17:13:10Z

[ Upstream commit 11ac0d7c3b5ba58232fb7dacb54371cbe75ec183 ] 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 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 Link: https://patch.msgid.link/20241119173108.5ea90828c2cc.I4f89e58572fb71ae48e47a81e74595cac410fbac@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin

wifi: ipw2x00: libipw_rx_any(): fix bad alignment

2024-12-14T19:03:54Z

[ Upstream commit 4fa4f049dc0d9741b16c96bcbf0108c85368a2b9 ] This patch fixes incorrect code alignment. ./drivers/net/wireless/intel/ipw2x00/libipw_rx.c:871:2-3: code aligned with following code on line 882. ./drivers/net/wireless/intel/ipw2x00/libipw_rx.c:886:2-3: code aligned with following code on line 900. Reported-by: Abaci Robot Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=11381 Signed-off-by: Jiapeng Chong Signed-off-by: Kalle Valo Link: https://patch.msgid.link/20241101060725.54640-1-jiapeng.chong@linux.alibaba.com Signed-off-by: Sasha Levin

Revert "wifi: iwlegacy: do not skip frames with bad FCS"

2024-12-05T13:01:57Z

[ Upstream commit 11597043d74809daf5d14256b96d6781749b3f82 ] This reverts commit 02b682d54598f61cbb7dbb14d98ec1801112b878. Alf reports that this commit causes the connection to eventually die on iwl4965. The reason is that rx_status.flag is zeroed after RX_FLAG_FAILED_FCS_CRC is set and mac80211 doesn't know the received frame is corrupted. Fixes: 02b682d54598 ("wifi: iwlegacy: do not skip frames with bad FCS") Reported-by: Alf Marius Closes: https://lore.kernel.org/r/60f752e8-787e-44a8-92ae-48bdfc9b43e7@app.fastmail.com/ Signed-off-by: Kalle Valo Link: https://patch.msgid.link/20241112142419.1023743-1-kvalo@kernel.org Signed-off-by: Sasha Levin

wifi: iwlwifi: mvm: tell iwlmei when we finished suspending

2024-12-05T13:01:56Z

[ Upstream commit d1a54ec21b8e7bca59141ff1ac6ce73e07d744f2 ] Since we no longer shut down the device in suspend, we also no longer call iwl_mvm_mei_device_state() and this is a problem because iwlmei expects this to be called when it runs its own suspend sequence. It checks mei->device_down in iwl_mei_remove() which is called upon suspend. Fix this by telling iwlmei when we're done accessing the device. When we'll wake up, the device should be untouched if CSME didn't use it during the suspend time. If CSME used it, we'll notice it through the CSR_FUNC_SCRATCH register. Fixes: e8bb19c1d590 ("wifi: iwlwifi: support fast resume") Signed-off-by: Emmanuel Grumbach Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20241028135215.525287b90af2.Ibf183824471ea5580d9276d104444e53191e6900@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin

wifi: iwlwifi: allow fast resume on ax200

2024-12-05T13:01:55Z

[ Upstream commit e53ebc72054efca12e0329d69342e3daf7250a5a ] This feature can be used on ax200 as well. It'll avoid to restart the firmware upon suspend / resume flow. Doing so also avoids releasing and re-allocating all the device related memory which makes the memory's subsystem task easier. Signed-off-by: Emmanuel Grumbach Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20241028135215.514efe0ce4c7.I60061277526302a75cadbba10452e94c54763f13@changeid Signed-off-by: Johannes Berg Stable-dep-of: d1a54ec21b8e ("wifi: iwlwifi: mvm: tell iwlmei when we finished suspending") Signed-off-by: Sasha Levin

wifi: iwlwifi: mvm: fix 6 GHz scan construction

2024-10-25T15:53:47Z

If more than 255 colocated APs exist for the set of all APs found during 2.4/5 GHz scanning, then the 6 GHz scan construction will loop forever since the loop variable has type u8, which can never reach the number found when that's bigger than 255, and is stored in a u32 variable. Also move it into the loops to have a smaller scope. Using a u32 there is fine, we limit the number of APs in the scan list and each has a limit on the number of RNR entries due to the frame size. With a limit of 1000 scan results, a frame size upper bound of 4096 (really it's more like ~2300) and a TBTT entry size of at least 11, we get an upper bound for the number of ~372k, well in the bounds of a u32. Cc: stable@vger.kernel.org Fixes: eae94cf82d74 ("iwlwifi: mvm: add support for 6GHz") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219375 Link: https://patch.msgid.link/20241023091744.f4baed5c08a1.I8b417148bbc8c5d11c101e1b8f5bf372e17bf2a7@changeid Signed-off-by: Johannes Berg

Revert "wifi: iwlwifi: remove retry loops in start"

2024-10-25T15:53:37Z

Revert commit dfdfe4be183b ("wifi: iwlwifi: remove retry loops in start"), it turns out that there's an issue with the PNVM load notification from firmware not getting processed, that this patch has been somewhat successfully papering over. Since this is being reported, revert the loop removal for now. We will later at least clean this up to only attempt to retry if there was a timeout, but currently we don't even bubble up the failure reason to the correct layer, only returning NULL. Fixes: dfdfe4be183b ("wifi: iwlwifi: remove retry loops in start") Signed-off-by: Emmanuel Grumbach Link: https://patch.msgid.link/20241022092212.4aa82a558a00.Ibdeff9c8f0d608bc97fc42024392ae763b6937b7@changeid Signed-off-by: Johannes Berg