summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/intel
AgeCommit message (Collapse)AuthorFilesLines
2023-04-20wifi: iwlwifi: mvm: protect TXQ list manipulationJohannes Berg4-34/+39
[ Upstream commit 923bf981eb6ecc027227716e30701bdcc1845fbf ] Some recent upstream debugging uncovered the fact that in iwlwifi, the TXQ list manipulation is racy. Introduce a new state bit for when the TXQ is completely ready and can be used without locking, and if that's not set yet acquire the lock to check everything correctly. Reviewed-by: Benjamin Berg <benjamin.berg@intel.com> Tested-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-04-20wifi: iwlwifi: mvm: fix mvmtxq->stopped handlingJohannes Berg4-5/+13
[ Upstream commit b58e3d4311b54b6dd0e37165277965da0c9eb21d ] This could race if the queue is redirected while full, then the flushing internally would start it while it's not yet usable again. Fix it by using two state bits instead of just one. Reviewed-by: Benjamin Berg <benjamin.berg@intel.com> Tested-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10wifi: iwl4965: Add missing check for create_singlethread_workqueue()Jiasheng Jiang1-2/+10
[ Upstream commit 26e6775f75517ad6844fe5b79bc5f3fa8c22ee61 ] Add the check for the return value of the create_singlethread_workqueue() in order to avoid NULL pointer dereference. Fixes: b481de9ca074 ("[IWLWIFI]: add iwlwifi wireless drivers") Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn> Acked-by: Stanislaw Gruszka <stf_xl@wp.pl> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230209010748.45454-1-jiasheng@iscas.ac.cn Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10wifi: iwl3945: Add missing check for create_singlethread_workqueueJiasheng Jiang1-4/+12
[ Upstream commit 1fdeb8b9f29dfd64805bb49475ac7566a3cb06cb ] Add the check for the return value of the create_singlethread_workqueue in order to avoid NULL pointer dereference. Fixes: b481de9ca074 ("[IWLWIFI]: add iwlwifi wireless drivers") Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn> Acked-by: Stanislaw Gruszka <stf_xl@wp.pl> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230208063032.42763-2-jiasheng@iscas.ac.cn Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10wifi: iwlwifi: mei: fix compilation errors in rfkill()Gregory Greenman1-3/+3
[ Upstream commit 9cbd5a8abca904441e36861e3a92961bec41d13f ] The rfkill() callback was invoked with wrong parameters. It was missed since MEI is defined now as depending on BROKEN. Fix that. Fixes: d288067ede4b ("wifi: iwlwifi: mei: avoid blocking sap messages handling due to rtnl lock") Fixes: 5aa7ce31bd84 ("wifi: iwlwifi: mei: make sure ownership confirmed message is sent") Fixes: 95170a46b7dd ("wifi: iwlwifi: mei: don't send SAP commands if AMT is disabled") Link: https://lore.kernel.org/r/20230126222821.305122-2-gregory.greenman@intel.com Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10wifi: ipw2200: fix memory leak in ipw_wdev_init()Zhengchao Shao1-2/+7
[ Upstream commit 9fe21dc626117fb44a8eb393713a86a620128ce3 ] In the error path of ipw_wdev_init(), exception value is returned, and the memory applied for in the function is not released. Also the memory is not released in ipw_pci_probe(). As a result, memory leakage occurs. So memory release needs to be added to the error path of ipw_wdev_init(). Fixes: a3caa99e6c68 ("libipw: initiate cfg80211 API conversion (v2)") Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221209012422.182669-1-shaozhengchao@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10wifi: ipw2x00: don't call dev_kfree_skb() under spin_lock_irqsave()Yang Yingliang1-1/+1
[ Upstream commit 45fc6d7461f18df2f238caf0cbc5acc4163203d1 ] It is not allowed to call kfree_skb() or consume_skb() from hardware interrupt context or with hardware interrupts being disabled. It should use dev_kfree_skb_irq() or dev_consume_skb_irq() instead. The difference between them is free reason, dev_kfree_skb_irq() means the SKB is dropped in error and dev_consume_skb_irq() means the SKB is consumed in normal. In this case, dev_kfree_skb() is called to free and drop the SKB when it's reset, so replace it with dev_kfree_skb_irq(). Compile tested only. Fixes: 43f66a6ce8da ("Add ipw2200 wireless driver.") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221208143826.2385218-1-yangyingliang@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10wifi: iwlegacy: common: don't call dev_kfree_skb() under spin_lock_irqsave()Yang Yingliang1-2/+2
[ Upstream commit 0c1528675d7a9787cb516b64d8f6c0f6f8efcb48 ] It is not allowed to call consume_skb() from hardware interrupt context or with interrupts being disabled. So replace dev_kfree_skb() with dev_consume_skb_irq() under spin_lock_irqsave(). Compile tested only. Fixes: 4bc85c1324aa ("Revert "iwlwifi: split the drivers for agn and legacy devices 3945/4965"") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Acked-by: Stanislaw Gruszka <stf_xl@wp.pl> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221207144013.70210-1-yangyingliang@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-01-24wifi: iwlwifi: fw: skip PPAG for JFJohannes Berg1-0/+5
[ Upstream commit 1c4c0b28b517d778d37900deedfe91088839f07a ] For JF RFs we don't support PPAG, but many firmware images lie about it. Always skip support for JF to avoid firmware errors when sending the command. Reported-and-tested-by: Íñigo Huguet <ihuguet@redhat.com> Link: https://lore.kernel.org/linux-wireless/CACT4oufQsqHGp6bah2c4+jPn2wG1oZqY=UKa_TmPx=F6Lxng8Q@mail.gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221213225723.2a43415d8990.I9ac210740a45b41f1b2e15274e1daf4284f2808a@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31wifi: iwlwifi: mvm: fix double free on tx path.Ben Greear1-1/+11
[ Upstream commit 0473cbae2137b963bd0eaa74336131cb1d3bc6c3 ] We see kernel crashes and lockups and KASAN errors related to ax210 firmware crashes. One of the KASAN dumps pointed at the tx path, and it appears there is indeed a way to double-free an skb. If iwl_mvm_tx_skb_sta returns non-zero, then the 'skb' sent into the method will be freed. But, in case where we build TSO skb buffer, the skb may also be freed in error case. So, return 0 in that particular error case and do cleanup manually. BUG: KASAN: use-after-free in __list_del_entry_valid+0x12/0x90 iwlwifi 0000:06:00.0: 0x00000000 | tsf hi Read of size 8 at addr ffff88813cfa4ba0 by task btserver/9650 CPU: 4 PID: 9650 Comm: btserver Tainted: G W 5.19.8+ #5 iwlwifi 0000:06:00.0: 0x00000000 | time gp1 Hardware name: Default string Default string/SKYBAY, BIOS 5.12 02/19/2019 Call Trace: <TASK> dump_stack_lvl+0x55/0x6d print_report.cold.12+0xf2/0x684 iwlwifi 0000:06:00.0: 0x1D0915A8 | time gp2 ? __list_del_entry_valid+0x12/0x90 kasan_report+0x8b/0x180 iwlwifi 0000:06:00.0: 0x00000001 | uCode revision type ? __list_del_entry_valid+0x12/0x90 __list_del_entry_valid+0x12/0x90 iwlwifi 0000:06:00.0: 0x00000048 | uCode version major tcp_update_skb_after_send+0x5d/0x170 __tcp_transmit_skb+0xb61/0x15c0 iwlwifi 0000:06:00.0: 0xDAA05125 | uCode version minor ? __tcp_select_window+0x490/0x490 iwlwifi 0000:06:00.0: 0x00000420 | hw version ? trace_kmalloc_node+0x29/0xd0 ? __kmalloc_node_track_caller+0x12a/0x260 ? memset+0x1f/0x40 ? __build_skb_around+0x125/0x150 ? __alloc_skb+0x1d4/0x220 ? skb_zerocopy_clone+0x55/0x230 iwlwifi 0000:06:00.0: 0x00489002 | board version ? kmalloc_reserve+0x80/0x80 ? rcu_read_lock_bh_held+0x60/0xb0 tcp_write_xmit+0x3f1/0x24d0 iwlwifi 0000:06:00.0: 0x034E001C | hcmd ? __check_object_size+0x180/0x350 iwlwifi 0000:06:00.0: 0x24020000 | isr0 tcp_sendmsg_locked+0x8a9/0x1520 iwlwifi 0000:06:00.0: 0x01400000 | isr1 ? tcp_sendpage+0x50/0x50 iwlwifi 0000:06:00.0: 0x48F0000A | isr2 ? lock_release+0xb9/0x400 ? tcp_sendmsg+0x14/0x40 iwlwifi 0000:06:00.0: 0x00C3080C | isr3 ? lock_downgrade+0x390/0x390 ? do_raw_spin_lock+0x114/0x1d0 iwlwifi 0000:06:00.0: 0x00200000 | isr4 ? rwlock_bug.part.2+0x50/0x50 iwlwifi 0000:06:00.0: 0x034A001C | last cmd Id ? rwlock_bug.part.2+0x50/0x50 ? lockdep_hardirqs_on_prepare+0xe/0x200 iwlwifi 0000:06:00.0: 0x0000C2F0 | wait_event ? __local_bh_enable_ip+0x87/0xe0 ? inet_send_prepare+0x220/0x220 iwlwifi 0000:06:00.0: 0x000000C4 | l2p_control tcp_sendmsg+0x22/0x40 sock_sendmsg+0x5f/0x70 iwlwifi 0000:06:00.0: 0x00010034 | l2p_duration __sys_sendto+0x19d/0x250 iwlwifi 0000:06:00.0: 0x00000007 | l2p_mhvalid ? __ia32_sys_getpeername+0x40/0x40 iwlwifi 0000:06:00.0: 0x00000000 | l2p_addr_match ? rcu_read_lock_held_common+0x12/0x50 ? rcu_read_lock_sched_held+0x5a/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? rcu_read_lock_sched_held+0x5a/0xd0 ? rcu_read_lock_sched_held+0x5a/0xd0 ? lock_release+0xb9/0x400 ? lock_downgrade+0x390/0x390 ? ktime_get+0x64/0x130 ? ktime_get+0x8d/0x130 ? rcu_read_lock_held_common+0x12/0x50 ? rcu_read_lock_sched_held+0x5a/0xd0 ? rcu_read_lock_held_common+0x12/0x50 ? rcu_read_lock_sched_held+0x5a/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? rcu_read_lock_bh_held+0xb0/0xb0 __x64_sys_sendto+0x6f/0x80 do_syscall_64+0x34/0xb0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f1d126e4531 Code: 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 48 8d 05 35 80 0c 00 41 89 ca 8b 00 85 c0 75 1c 45 31 c9 45 31 c0 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 67 c3 66 0f 1f 44 00 00 55 48 83 ec 20 48 89 RSP: 002b:00007ffe21a679d8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000000000000ffdc RCX: 00007f1d126e4531 RDX: 0000000000010000 RSI: 000000000374acf0 RDI: 0000000000000014 RBP: 00007ffe21a67ac0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000010 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000000 </TASK> Allocated by task 9650: kasan_save_stack+0x1c/0x40 __kasan_slab_alloc+0x6d/0x90 kmem_cache_alloc_node+0xf3/0x2b0 __alloc_skb+0x191/0x220 tcp_stream_alloc_skb+0x3f/0x330 tcp_sendmsg_locked+0x67c/0x1520 tcp_sendmsg+0x22/0x40 sock_sendmsg+0x5f/0x70 __sys_sendto+0x19d/0x250 __x64_sys_sendto+0x6f/0x80 do_syscall_64+0x34/0xb0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Freed by task 9650: kasan_save_stack+0x1c/0x40 kasan_set_track+0x21/0x30 kasan_set_free_info+0x20/0x30 __kasan_slab_free+0x102/0x170 kmem_cache_free+0xc8/0x3e0 iwl_mvm_mac_itxq_xmit+0x124/0x270 [iwlmvm] ieee80211_queue_skb+0x874/0xd10 [mac80211] ieee80211_xmit_fast+0xf80/0x1180 [mac80211] __ieee80211_subif_start_xmit+0x287/0x680 [mac80211] ieee80211_subif_start_xmit+0xcd/0x730 [mac80211] dev_hard_start_xmit+0xf6/0x420 __dev_queue_xmit+0x165b/0x1b50 ip_finish_output2+0x66e/0xfb0 __ip_finish_output+0x487/0x6d0 ip_output+0x11c/0x350 __ip_queue_xmit+0x36b/0x9d0 __tcp_transmit_skb+0xb35/0x15c0 tcp_write_xmit+0x3f1/0x24d0 tcp_sendmsg_locked+0x8a9/0x1520 tcp_sendmsg+0x22/0x40 sock_sendmsg+0x5f/0x70 __sys_sendto+0x19d/0x250 __x64_sys_sendto+0x6f/0x80 do_syscall_64+0x34/0xb0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 The buggy address belongs to the object at ffff88813cfa4b40 which belongs to the cache skbuff_fclone_cache of size 472 The buggy address is located 96 bytes inside of 472-byte region [ffff88813cfa4b40, ffff88813cfa4d18) The buggy address belongs to the physical page: page:ffffea0004f3e900 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88813cfa6c40 pfn:0x13cfa4 head:ffffea0004f3e900 order:2 compound_mapcount:0 compound_pincount:0 flags: 0x5fff8000010200(slab|head|node=0|zone=2|lastcpupid=0x3fff) raw: 005fff8000010200 ffffea0004656b08 ffffea0008e8cf08 ffff8881081a5240 raw: ffff88813cfa6c40 0000000000170015 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88813cfa4a80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88813cfa4b00: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb >ffff88813cfa4b80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff88813cfa4c00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88813cfa4c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Fixes: 08f7d8b69aaf ("iwlwifi: mvm: bring back mvm GSO code") Link: https://lore.kernel.org/linux-wireless/20220928193057.16132-1-greearb@candelatech.com/ Tested-by: Amol Jawale <amol.jawale@candelatech.com> Signed-off-by: Ben Greear <greearb@candelatech.com> Link: https://lore.kernel.org/r/20221123225313.21b1ee31d666.I3b3ba184433dd2a544d91eeeda29b467021824ae@changeid Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31wifi: iwlwifi: mei: fix potential NULL-ptr deref after cloneJohannes Berg1-3/+7
[ Upstream commit d3df49dda431f7ae4132a9a0ac25a5134c04e812 ] If cloning the SKB fails, don't try to use it, but rather return as if we should pass it. Coverity CID: 1503456 Fixes: 2da4366f9e2c ("iwlwifi: mei: add the driver to allow cooperation with CSME") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20221030191011.0ce03ba99601.I87960b7cb0a3d16b9fd8d9144027e7e2587f5a58@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31wifi: iwlwifi: mei: avoid blocking sap messages handling due to rtnl lockAvraham Stern1-20/+37
[ Upstream commit d288067ede4b375e72daf7f9a98d937ede11a311 ] The AMT_STATE sap message handler tries to take the rtnl lock. This means that in case the rtnl lock is already taken, sap messages will not be processed. When an interface is brought up, the host requests ownership from csme. However, since the rtnl lock is already held, if there is a pending amt state message, the host will not be able to read the ownership confirm message because the amt state message handler is pending. As a result, the host fails to get ownership although csme granted it. Fix it by moving the part that needs the rtnl lock into a dedicated worker, so handling sap messages can continue. Fixes: 2da4366f9e2c ("iwlwifi: mei: add the driver to allow cooperation with CSME") Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20221030191011.8599f2b4e9dd.I518f79e9099bf815c5f8d90235b4ce3250f59970@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31wifi: iwlwifi: mei: fix tx DHCP packet for devices with new Tx APIEmmanuel Grumbach1-1/+7
[ Upstream commit bcd68b3dbe78b7b0f7b6b55162cf1eff1e7fff9e ] Devices with new Tx API have the IV introduced by the HW and it is not present in the skb at all. Hence we don't need to tell iwl_mvm_mei_tx_copy_to_csme to jump over 8 bytes to get to the ethernet header. Fixes: 2da4366f9e2c ("iwlwifi: mei: add the driver to allow cooperation with CSME") Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20221030191011.12dc42133502.Idd744ffeeb84b880eb497963ee02563cbb959a42@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31wifi: iwlwifi: mei: don't send SAP commands if AMT is disabledEmmanuel Grumbach1-41/+44
[ Upstream commit 95170a46b7dddbc3ac31b20ef2e8fa9d556d783d ] We should not send any SAP command to CSME if AMT is disabled. Reported-by: Toke Høiland-Jørgensen <toke@toke.dk> Fixes: 2da4366f9e2c ("iwlwifi: mei: add the driver to allow cooperation with CSME") Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20221030191011.ea222d41c781.Ifc90ddc3e35187683ff7f59371d792b61c8854c8@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31wifi: iwlwifi: mei: make sure ownership confirmed message is sentAvraham Stern5-16/+29
[ Upstream commit 5aa7ce31bd84c2f4f059200f06c537c920cbb458 ] It is possible that CSME will try to take ownership while the driver is stopping. In this case, if the CSME takes ownership message arrives after the driver started unregistering, the iwl_mei_cache->ops is already invalid, so the host will not answer with the ownership confirmed message. Similarly, if the take ownership message arrived after the mac was stopped or when iwl_mvm_up() failed, setting rfkill will not trigger sending the confirm message. As a result, CSME will not take ownership, which will result in a disconnection. Fix it by sending the ownership confirmed message immediately in such cases. Fixes: 2da4366f9e2c ("iwlwifi: mei: add the driver to allow cooperation with CSME") Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20221030191011.b2a4c009e3e6.I7f931b7ee8b168e8ac88b11f23bff98b7ed3cb19@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-10-17Merge tag 'random-6.1-rc1-for-linus' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/crng/random Pull more random number generator updates from Jason Donenfeld: "This time with some large scale treewide cleanups. The intent of this pull is to clean up the way callers fetch random integers. The current rules for doing this right are: - If you want a secure or an insecure random u64, use get_random_u64() - If you want a secure or an insecure random u32, use get_random_u32() The old function prandom_u32() has been deprecated for a while now and is just a wrapper around get_random_u32(). Same for get_random_int(). - If you want a secure or an insecure random u16, use get_random_u16() - If you want a secure or an insecure random u8, use get_random_u8() - If you want secure or insecure random bytes, use get_random_bytes(). The old function prandom_bytes() has been deprecated for a while now and has long been a wrapper around get_random_bytes() - If you want a non-uniform random u32, u16, or u8 bounded by a certain open interval maximum, use prandom_u32_max() I say "non-uniform", because it doesn't do any rejection sampling or divisions. Hence, it stays within the prandom_*() namespace, not the get_random_*() namespace. I'm currently investigating a "uniform" function for 6.2. We'll see what comes of that. By applying these rules uniformly, we get several benefits: - By using prandom_u32_max() with an upper-bound that the compiler can prove at compile-time is ≤65536 or ≤256, internally get_random_u16() or get_random_u8() is used, which wastes fewer batched random bytes, and hence has higher throughput. - By using prandom_u32_max() instead of %, when the upper-bound is not a constant, division is still avoided, because prandom_u32_max() uses a faster multiplication-based trick instead. - By using get_random_u16() or get_random_u8() in cases where the return value is intended to indeed be a u16 or a u8, we waste fewer batched random bytes, and hence have higher throughput. This series was originally done by hand while I was on an airplane without Internet. Later, Kees and I worked on retroactively figuring out what could be done with Coccinelle and what had to be done manually, and then we split things up based on that. So while this touches a lot of files, the actual amount of code that's hand fiddled is comfortably small" * tag 'random-6.1-rc1-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/crng/random: prandom: remove unused functions treewide: use get_random_bytes() when possible treewide: use get_random_u32() when possible treewide: use get_random_{u8,u16}() when possible, part 2 treewide: use get_random_{u8,u16}() when possible, part 1 treewide: use prandom_u32_max() when possible, part 2 treewide: use prandom_u32_max() when possible, part 1
2022-10-12treewide: use prandom_u32_max() when possible, part 1Jason A. Donenfeld1-1/+1
Rather than incurring a division or requesting too many random bytes for the given range, use the prandom_u32_max() function, which only takes the minimum required bytes from the RNG and avoids divisions. This was done mechanically with this coccinelle script: @basic@ expression E; type T; identifier get_random_u32 =~ "get_random_int|prandom_u32|get_random_u32"; typedef u64; @@ ( - ((T)get_random_u32() % (E)) + prandom_u32_max(E) | - ((T)get_random_u32() & ((E) - 1)) + prandom_u32_max(E * XXX_MAKE_SURE_E_IS_POW2) | - ((u64)(E) * get_random_u32() >> 32) + prandom_u32_max(E) | - ((T)get_random_u32() & ~PAGE_MASK) + prandom_u32_max(PAGE_SIZE) ) @multi_line@ identifier get_random_u32 =~ "get_random_int|prandom_u32|get_random_u32"; identifier RAND; expression E; @@ - RAND = get_random_u32(); ... when != RAND - RAND %= (E); + RAND = prandom_u32_max(E); // Find a potential literal @literal_mask@ expression LITERAL; type T; identifier get_random_u32 =~ "get_random_int|prandom_u32|get_random_u32"; position p; @@ ((T)get_random_u32()@p & (LITERAL)) // Add one to the literal. @script:python add_one@ literal << literal_mask.LITERAL; RESULT; @@ value = None if literal.startswith('0x'): value = int(literal, 16) elif literal[0] in '123456789': value = int(literal, 10) if value is None: print("I don't know how to handle %s" % (literal)) cocci.include_match(False) elif value == 2**32 - 1 or value == 2**31 - 1 or value == 2**24 - 1 or value == 2**16 - 1 or value == 2**8 - 1: print("Skipping 0x%x for cleanup elsewhere" % (value)) cocci.include_match(False) elif value & (value + 1) != 0: print("Skipping 0x%x because it's not a power of two minus one" % (value)) cocci.include_match(False) elif literal.startswith('0x'): coccinelle.RESULT = cocci.make_expr("0x%x" % (value + 1)) else: coccinelle.RESULT = cocci.make_expr("%d" % (value + 1)) // Replace the literal mask with the calculated result. @plus_one@ expression literal_mask.LITERAL; position literal_mask.p; expression add_one.RESULT; identifier FUNC; @@ - (FUNC()@p & (LITERAL)) + prandom_u32_max(RESULT) @collapse_ret@ type T; identifier VAR; expression E; @@ { - T VAR; - VAR = (E); - return VAR; + return E; } @drop_var@ type T; identifier VAR; @@ { - T VAR; ... when != VAR } Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Yury Norov <yury.norov@gmail.com> Reviewed-by: KP Singh <kpsingh@kernel.org> Reviewed-by: Jan Kara <jack@suse.cz> # for ext4 and sbitmap Reviewed-by: Christoph Böhmwalder <christoph.boehmwalder@linbit.com> # for drbd Acked-by: Jakub Kicinski <kuba@kernel.org> Acked-by: Heiko Carstens <hca@linux.ibm.com> # for s390 Acked-by: Ulf Hansson <ulf.hansson@linaro.org> # for mmc Acked-by: Darrick J. Wong <djwong@kernel.org> # for xfs Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
2022-10-11wifi: iwlwifi: mvm: fix double list_add at iwl_mvm_mac_wake_tx_queue (other ↵Jose Ignacio Tornos Martinez1-0/+2
cases) BUGs like this are still reproducible: [ 31.509616] list_add corruption. prev->next should be next (ffff8f8644242300), but was ffff8f86493fd300. (prev=ffff8f86493fd300). [ 31.521544] ------------[ cut here ]------------ [ 31.526248] kernel BUG at lib/list_debug.c:30! [ 31.530781] invalid opcode: 0000 [#1] PREEMPT SMP PTI [ 31.535831] CPU: 1 PID: 626 Comm: wpa_supplicant Not tainted 6.0.0+ #7 [ 31.542450] Hardware name: Dell Inc. Inspiron 660s/0478VN , BIOS A07 08/24/2012 [ 31.550484] RIP: 0010:__list_add_valid.cold+0x3a/0x5b [ 31.555537] Code: f2 4c 89 c1 48 89 fe 48 c7 c7 28 20 69 89 e8 4c e3 fd ff 0f 0b 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 d0 1f 69 89 e8 35 e3 fd ff <0f> 0b 4c 89 c1 48 c7 c7 78 1f 69 89 e8 24 e3 fd ff 0f 0b 48 c7 c7 [ 31.574605] RSP: 0018:ffff9f6f00dc3748 EFLAGS: 00010286 [ 31.579990] RAX: 0000000000000075 RBX: ffff8f8644242080 RCX: 0000000000000000 [ 31.587155] RDX: 0000000000000201 RSI: ffffffff8967862d RDI: 00000000ffffffff [ 31.594482] RBP: ffff8f86493fd2e8 R08: 0000000000000000 R09: 00000000ffffdfff [ 31.601735] R10: ffff9f6f00dc3608 R11: ffffffff89f46128 R12: ffff8f86493fd300 [ 31.608986] R13: ffff8f86493fd300 R14: ffff8f8644242300 R15: ffff8f8643dd3f2c [ 31.616151] FS: 00007f3bb9a707c0(0000) GS:ffff8f865a300000(0000) knlGS:0000000000000000 [ 31.624447] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 31.630286] CR2: 00007fe3647d5600 CR3: 00000001125a6002 CR4: 00000000000606e0 [ 31.637539] Call Trace: [ 31.639936] <TASK> [ 31.642143] iwl_mvm_mac_wake_tx_queue+0x71/0x90 [iwlmvm] [ 31.647569] ieee80211_queue_skb+0x4b6/0x720 [mac80211] ... So, it is necessary to extend the applied solution with commit 14a3aacf517a9 ("iwlwifi: mvm: fix double list_add at iwl_mvm_mac_wake_tx_queue") to all other cases where the station queues are invalidated and the related lists are not emptied. Because, otherwise as before, if some new element is added later to the list in iwl_mvm_mac_wake_tx_queue, it can match with the old one and produce the same commented BUG. That is, in order to avoid this problem completely, we must also remove the related lists for the other cases when station queues are invalidated. Fixes: cfbc6c4c5b91c ("iwlwifi: mvm: support mac80211 TXQs model") Reported-by: Petr Stourac <pstourac@redhat.com> Tested-by: Petr Stourac <pstourac@redhat.com> Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221010081611.145027-1-jtornosm@redhat.com
2022-09-30Merge tag 'wireless-next-2022-09-30' of ↵Jakub Kicinski33-491/+937
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Kalle Valo says: ==================== wireless-next patches for v6.1 Few stack changes and lots of driver changes in this round. brcmfmac has more activity as usual and it gets new hardware support. ath11k improves WCN6750 support and also other smaller features. And of course changes all over. Note: in early September wireless tree was merged to wireless-next to avoid some conflicts with mac80211 patches, this shouldn't cause any problems but wanted to mention anyway. Major changes: mac80211 - refactoring and preparation for Wi-Fi 7 Multi-Link Operation (MLO) feature continues brcmfmac - support CYW43439 SDIO chipset - support BCM4378 on Apple platforms - support CYW89459 PCIe chipset rtw89 - more work to get rtw8852c supported - P2P support - support for enabling and disabling MSDU aggregation via nl80211 mt76 - tx status reporting improvements ath11k - cold boot calibration support on WCN6750 - Target Wake Time (TWT) debugfs support for STA interface - support to connect to a non-transmit MBSSID AP profile - enable remain-on-channel support on WCN6750 - implement SRAM dump debugfs interface - enable threaded NAPI on all hardware - WoW support for WCN6750 - support to provide transmit power from firmware via nl80211 - support to get power save duration for each client - spectral scan support for 160 MHz wcn36xx - add SNR from a received frame as a source of system entropy * tag 'wireless-next-2022-09-30' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (231 commits) wifi: rtl8xxxu: Improve rtl8xxxu_queue_select wifi: rtl8xxxu: Fix AIFS written to REG_EDCA_*_PARAM wifi: rtl8xxxu: gen2: Enable 40 MHz channel width wifi: rtw89: 8852b: configure DLE mem wifi: rtw89: check DLE FIFO size with reserved size wifi: rtw89: mac: correct register of report IMR wifi: rtw89: pci: set power cut closed for 8852be wifi: rtw89: pci: add to do PCI auto calibration wifi: rtw89: 8852b: implement chip_ops::{enable,disable}_bb_rf wifi: rtw89: add DMA busy checking bits to chip info wifi: rtw89: mac: define DMA channel mask to avoid unsupported channels wifi: rtw89: pci: mask out unsupported TX channels iwlegacy: Replace zero-length arrays with DECLARE_FLEX_ARRAY() helper ipw2x00: Replace zero-length array with DECLARE_FLEX_ARRAY() helper wifi: iwlwifi: Track scan_cmd allocation size explicitly brcmfmac: Remove the call to "dtim_assoc" IOVAR brcmfmac: increase dcmd maximum buffer size brcmfmac: Support 89459 pcie brcmfmac: increase default max WOWL patterns to 16 cw1200: fix incorrect check to determine if no element is found in list ... ==================== Link: https://lore.kernel.org/r/20220930150413.A7984C433D6@smtp.kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-29net: drop the weight argument from netif_napi_addJakub Kicinski1-1/+1
We tell driver developers to always pass NAPI_POLL_WEIGHT as the weight to netif_napi_add(). This may be confusing to newcomers, drop the weight argument, those who really need to tweak the weight can use netif_napi_add_weight(). Acked-by: Marc Kleine-Budde <mkl@pengutronix.de> # for CAN Link: https://lore.kernel.org/r/20220927132753.750069-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-28iwlegacy: Replace zero-length arrays with DECLARE_FLEX_ARRAY() helperGustavo A. R. Silva1-2/+2
Zero-length arrays are deprecated and we are moving towards adopting C99 flexible-array members, instead. So, replace zero-length arrays declarations in anonymous union with the new DECLARE_FLEX_ARRAY() helper macro. This helper allows for flexible-array members in unions. Link: https://github.com/KSPP/linux/issues/193 Link: https://github.com/KSPP/linux/issues/223 Link: https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/YzIvzc0jsYLigO8a@work
2022-09-28ipw2x00: Replace zero-length array with DECLARE_FLEX_ARRAY() helperGustavo A. R. Silva1-1/+1
Zero-length arrays are deprecated and we are moving towards adopting C99 flexible-array members, instead. So, replace zero-length arrays declarations in anonymous union with the new DECLARE_FLEX_ARRAY() helper macro. This helper allows for flexible-array members in unions. Link: https://github.com/KSPP/linux/issues/193 Link: https://github.com/KSPP/linux/issues/220 Link: https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/YzIeULWc17XSIglv@work
2022-09-28wifi: iwlwifi: Track scan_cmd allocation size explicitlyKees Cook5-7/+16
In preparation for reducing the use of ksize(), explicitly track the size of scan_cmd allocations. This also allows for noticing if the scan size changes unexpectedly. Note that using ksize() was already incorrect here, in the sense that ksize() would not match the actual allocation size, which would trigger future run-time allocation bounds checking. (In other words, memset() may know how large scan_cmd was allocated for, but ksize() will return the upper bounds of the actually allocated memory, causing a run-time warning about an overflow.) Cc: Gregory Greenman <gregory.greenman@intel.com> Cc: Kalle Valo <kvalo@kernel.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Luca Coelho <luciano.coelho@intel.com> Cc: Johannes Berg <johannes.berg@intel.com> Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Cc: Miri Korenblit <miriam.rachel.korenblit@intel.com> Cc: Ilan Peer <ilan.peer@intel.com> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220923220853.3302056-1-keescook@chromium.org
2022-09-22Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski2-2/+3
drivers/net/ethernet/freescale/fec.h 7b15515fc1ca ("Revert "fec: Restart PPS after link state change"") 40c79ce13b03 ("net: fec: add stop mode support for imx8 platform") https://lore.kernel.org/all/20220921105337.62b41047@canb.auug.org.au/ drivers/pinctrl/pinctrl-ocelot.c c297561bc98a ("pinctrl: ocelot: Fix interrupt controller") 181f604b33cd ("pinctrl: ocelot: add ability to be used in a non-mmio configuration") https://lore.kernel.org/all/20220921110032.7cd28114@canb.auug.org.au/ tools/testing/selftests/drivers/net/bonding/Makefile bbb774d921e2 ("net: Add tests for bonding and team address list management") 152e8ec77640 ("selftests/bonding: add a test for bonding lladdr target") https://lore.kernel.org/all/20220921110437.5b7dbd82@canb.auug.org.au/ drivers/net/can/usb/gs_usb.c 5440428b3da6 ("can: gs_usb: gs_can_open(): fix race dev->can.state condition") 45dfa45f52e6 ("can: gs_usb: add RX and TX hardware timestamp support") https://lore.kernel.org/all/84f45a7d-92b6-4dc5-d7a1-072152fab6ff@tessares.net/ Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-22Merge tag 'iwlwifi-next-for-kalle-2022-09-18' of ↵Kalle Valo13-413/+846
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next iwlwifi patches for v6.1
2022-09-22wifi: ipw2x00: fix array of flexible structures warningsJohannes Berg2-12/+11
There are a number of these here, fix them by using appropriate casts. No binary changes. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220904212910.645346411660.I471e8fadce54ea262920828f25b8e84545bcd07e@changeid
2022-09-18wifi: iwlwifi: mvm: d3: parse keys from wowlan info notificationNaftali Goldstein1-83/+88
This notification replaces the WOWLAN_GET_STATUSES command-and-response, so it's required to parse all the keys in the notification just like what happened when that command was used. Move around a few required static functions in order to avoid forward declarations. Signed-off-by: Naftali Goldstein <naftali.goldstein@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20220906161827.ca3fb23cab81.I0a9fe7729af4567b98813bc51bad13ee5512a0ae@changeid Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
2022-09-18wifi: iwlwifi: mvm: iterate over interfaces after an assert in d3Yedidya Benshimol1-7/+11
In recent patches notifications based d3 resume flow was added, and the resume flow was changed. Currently, when resuming from d3 during which an assert was thrown, the resume flow skips the iteration over active interfaces preventing the sta to reconnect to the ap. Perform the iteration in case an assert was thrown to fix it. Signed-off-by: Yedidya Benshimol <yedidya.ben.shimol@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20220906161827.ad888cc6cd91.Ib56e416fce17df089edf76d22896430df5ebe080@changeid Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
2022-09-18wifi: iwlwifi: mvm: trigger resume flow before wait for notificationsHaim, Dreyfuss1-34/+43
We have recently enabled resume flow based on notifications. These notifications are sent by the FW when completing the resume flow. From IWL_DEVICE_FAMILY_AX210 the resume flow is triggered by the transport layer on iwl_trans_d3_resume. On IWL_DEVICE_FAMILY_22000 and earlier we trigger the resume flow by sending the D0I3 command. Currently, we are waiting for the notifications before sending the command, the notifications won't be sent by the FW since there is no resume trigger to piggyback on. Send the command before starting the wait flow to fix it. Signed-off-by: Haim, Dreyfuss <haim.dreyfuss@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20220906161827.5f0f251edf9c.Ia49ab73105af6f52aa7d318f4984edecd3b0671a@changeid Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
2022-09-18wifi: iwlwifi: mvm: Add handling for scan offload match info notificationIlan Peer4-59/+166
To support FW versions that send the scan match information as an asynchronous notification. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20220906161827.bbc5602d0b6f.I1329c231f82e7bf18f7dba0ccbd9f2d4080cbfc1@changeid Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
2022-09-18wifi: iwlwifi: mvm: enable resume based on notificationsHaim Dreyfuss1-2/+11
We have recently added support for resume based on notifications. Enable it. Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20220906161827.a6344ba23df5.I09fce8cf5aac1d46b40ae81b1abcf7a0e54af196@changeid Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
2022-09-18wifi: iwlwifi: mvm: Add support for d3 end notificationHaim Dreyfuss4-4/+44
Due to IMR, when host returns from hibernate, commands cannot be sent as part of the resume flow, and so after ending d3 the FW needs to send notifications instead of responses. This notification indicates whether a fw reset is required. Signed-off-by: Yedidya Benshimol <yedidya.ben.shimol@intel.com> Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20220906161827.898ecba881b2.I13eb69bb5af08b9ac33043647eaed6b8d50e8659@changeid Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
2022-09-18wifi: iwlwifi: mvm: Add support for wowlan wake packet notificationHaim Dreyfuss4-28/+118
The wowlan info notification is quite big. (~750 bytes without the wake packet itself). The max FW notification size is ~2K. There might be cases where the wake packet gets truncated because of this limit. Separating the wake packet from the wowlan info notification allows us to get more data without trimming it. Note: we currently limit the wake packet to 1600 bytes. Signed-off-by: Yedidya Benshimol <yedidya.ben.shimol@intel.com> Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20220906161827.06d1e6aecf10.Ib3d6a46ffe71d10cbc69bdb5654e6b14c28df245@changeid Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
2022-09-18wifi: iwlwifi: mvm: Add support for wowlan info notificationHaim Dreyfuss4-44/+230
IMR (Isolated Memory Regions) is a mechanism to protect memory regions from unwarranted access by agents in the system that should not have access to that memory. When IMR is enabled, pages in the DRAM will be located within the IMR memory space, accessible only by the device. As a side effect, during S4 (a.k.a hibernate) the IMR memory space is not retained. While the DRAM is saved to the disk and restored by the OS upon resume, the IMR, which is hidden from the OS neither saved upon suspend nor restored upon resume. As a consequence of the above, it turned out that commands cannot be sent as part of the resume flow, and so after ending d3 the FW needs to use notifications instead of cmd-resp. The resume flow becomes asynchronous, with a series of notifications, starting with wowlan_info_notif, through wowlan_pkt_notif and complete the resume flow by d3_end_notif. This patch adds the support for wowlan info notification. The wake packet has been removed from the wowlan info struct and will be handled in a dedicated notification. Signed-off-by: Yedidya Benshimol <yedidya.ben.shimol@intel.com> Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20220906161827.3ce8deefd929.Ieba8610e8bb4bec788076371ae38becb4a3d20d5@changeid Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
2022-09-18wifi: iwlwifi: mvm: don't check D0I3 versionHaim Dreyfuss3-30/+0
This code is dead, even old FW versions don't use it. The IWL_D0I3_RESET_REQUIRE flag will be sent by the FW via a notification, instead of command, the notification handler will be introduced later in the series. Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20220906161827.87c82482229a.I70456c38ed8f7beb7d62dd618f58e7dc0a7d33b2@changeid Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
2022-09-18wifi: iwlwifi: cfg: remove IWL_DEVICE_BZ_COMMON macroJohannes Berg1-6/+3
We only have a single use of this inside the IWL_DEVICE_BZ macro, so just combine the contents here. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20220906161827.23d6c92e9a11.I4a11928a6d698079dc742e3ba3d3ce6fd7a878d1@changeid Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
2022-09-18wifi: iwlwifi: mvm: refactor iwl_mvm_set_sta_rate() a bitJohannes Berg1-13/+12
Use a switch statement over the rate type instead of the if chain, to simplify. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20220906161827.623e32931b67.Id743a7879e84ae37a849179e536c58b1bf55380f@changeid Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
2022-09-18wifi: iwlwifi: mvm: rxmq: further unify some VHT/HE codeJohannes Berg1-22/+14
There's some duplication here, unify it so that adding EHT becomes easier. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20220906161827.d1e8673b9443.I6d81fc9dd0856d75e3a799c23f0f8d212b077fca@changeid Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
2022-09-18wifi: iwlwifi: mvm: rxmq: refactor mac80211 rx_status settingJohannes Berg1-191/+165
There's a bunch of duplicated code in the normal data RX and the no-data RX paths, refactor that. Note that we're evidently not implementing the 6 GHz band in the no-data path correctly, need to fix that in firmware first. Also, we were setting the NSS differently, keep doing that, but just override the previous values. Note also that we used to drop frames with bad rate data, to simplify that just report rate 0 and continue. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20220906161827.a81580d5e769.I3ee7a1fe1adf8684c48713dbbdc2cbc60bd24cd1@changeid Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
2022-09-18wifi: iwlwifi: mvm: fix typo in struct iwl_rx_no_data APIJohannes Berg1-2/+2
The version 2 is also for RX, of course, that's just a typo. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20220906161827.80f7eda56163.Ib783512104f0c135695b4d59b637f3eef3e8f537@changeid Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
2022-09-18wifi: iwlwifi: pcie: add support for BZ devicesYaara Baruch3-2/+53
Add support in BZ-FM and BZ-GL devices. Adjust current structs steps to differ between the new devices. Signed-off-by: Yaara Baruch <yaara.baruch@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20220906161827.0b7fc8487039.I984dcb58272e2f38c835e7aaa7e1ac646bc2f65e@changeid Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
2022-09-12wifi: iwlwifi: Mark IWLMEI as brokenToke Høiland-Jørgensen1-0/+1
The iwlmei driver breaks iwlwifi when returning from suspend. The interface ends up in the 'down' state after coming back from suspend. And iwd doesn't touch the interface state, but wpa_supplicant does, so the bug only happens on iwd. The bug report[0] has been open for four months now, and no fix seems to be forthcoming. Since just disabling the iwlmei driver works as a workaround, let's mark the config option as broken until it can be fixed properly. [0] https://bugzilla.kernel.org/show_bug.cgi?id=215937 Fixes: 2da4366f9e2c ("iwlwifi: mei: add the driver to allow cooperation with CSME") Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com> Acked-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220907134450.1183045-1-toke@toke.dk
2022-09-08Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netPaolo Abeni1-4/+1
drivers/net/ethernet/freescale/fec.h 7d650df99d52 ("net: fec: add pm_qos support on imx6q platform") 40c79ce13b03 ("net: fec: add stop mode support for imx8 platform") Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-09-07wifi: ipw2100: fix warnings about non-kernel-docJohannes Berg1-2/+2
Just remove the extra asterisk to make it not be kernel-doc formatted. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220904212910.8169e8c9090c.I0357e80cc86be2d4ac6205d1f53568444dcf7c9b@changeid
2022-09-07wifi: iwlwifi: calib: Refactor iwl_calib_result usage for clarityKees Cook3-15/+17
In preparation for FORTIFY_SOURCE performing run-time destination buffer bounds checking for memcpy(), refactor the use of struct iwl_calib_result: - Have struct iwl_calib_result contain struct iwl_calib_cmd since functions expect to operate on the "data" flex array in "cmd", which follows the "hdr" member. - Switch argument passing around to use struct iwl_calib_cmd instead of struct iwl_calib_hdr to prepare functions to see the "data" member. - Change iwl_calib_set()'s "len" argument to a size_t since it is always unsigned and is normally receiving the output of sizeof(). - Add an explicit length sanity check in iwl_calib_set(). - Adjust the memcpy() to avoid copying across the now visible composite flex array structure. This avoids the future run-time warning: memcpy: detected field-spanning write (size 8) of single field "&res->hdr" (size 4) Cc: Luca Coelho <luciano.coelho@intel.com> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Lee Jones <lee.jones@linaro.org> Cc: Johannes Berg <johannes.berg@intel.com> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Reported-by: Andy Lavr <andy.lavr@gmail.com> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220901204558.2256458-1-keescook@chromium.org
2022-09-07wifi: iwlwifi: don't spam logs with NSS>2 messagesJason A. Donenfeld1-2/+2
I get a log line like this every 4 seconds when connected to my AP: [15650.221468] iwlwifi 0000:09:00.0: Got NSS = 4 - trimming to 2 Looking at the code, this seems to be related to a hardware limitation, and there's nothing to be done. In an effort to keep my dmesg manageable, downgrade this error to "debug" rather than "info". Cc: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220905172246.105383-1-Jason@zx2c4.com
2022-09-06wifi: mac80211: keep A-MSDU data in sta and per-linkBenjamin Berg5-21/+24
The A-MSDU data needs to be stored per-link and aggregated into a single value for the station. Add a new struct ieee_80211_sta_aggregates in order to store this data and a new function ieee80211_sta_recalc_aggregates to update the current data for the STA. Note that in the non MLO case the pointer in ieee80211_sta will directly reference the data in deflink.agg, which means that recalculation may be skipped in that case. Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-09-06wifi: mac80211: make smps_mode per-linkBenjamin Berg7-18/+18
The SMPS power save mode needs to be per-link rather than being shared for all links. As such, move it into struct ieee80211_link_sta. Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-09-06Merge remote-tracking branch 'wireless/main' into wireless-nextJohannes Berg1-4/+1
Merge wireless/main to get the rx.link fix, which is needed for further work in this area. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-09-02wifi: move from strlcpy with unused retval to strscpyWolfram Sang3-7/+7
Follow the advice of the below link and prefer 'strscpy' in this subsystem. Conversion is 1:1 because the return value is not used. Generated by a coccinelle script. Link: https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmknw@mail.gmail.com/ Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220830201457.7984-2-wsa+renesas@sang-engineering.com
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-15 20:37:15 +0300