summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-05-17Merge branch '100GbE' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue Tony nguyen says: ==================== Intel Wired LAN Driver Updates 2023-05-16 This series contains updates to ice and iavf drivers. Ahmed adds setting of missed condition for statistics which caused incorrect reporting of values for ice. For iavf, he removes a call to set VLAN offloads during re-initialization which can cause incorrect values to be set. Dawid adds checks to ensure VF is ready to be reset before executing commands that will require it to be reset on ice. --- v2: Patch 2 - Redo commit message ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-17net: dsa: mv88e6xxx: Fix mv88e6393x EPC write command offsetMarco Migliore
According to datasheet, the command opcode must be specified into bits [14:12] of the Extended Port Control register (EPC). Fixes: de776d0d316f ("net: dsa: mv88e6xxx: add support for mv88e6393x family") Signed-off-by: Marco Migliore <m.migliore@tiesse.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-17cassini: Fix a memory leak in the error handling path of cas_init_one()Christophe JAILLET
cas_saturn_firmware_init() allocates some memory using vmalloc(). This memory is freed in the .remove() function but not it the error handling path of the probe. Add the missing vfree() to avoid a memory leak, should an error occur. Fixes: fcaa40669cd7 ("cassini: use request_firmware") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-17tun: Fix memory leak for detached NAPI queue.Kuniyuki Iwashima
syzkaller reported [0] memory leaks of sk and skb related to the TUN device with no repro, but we can reproduce it easily with: struct ifreq ifr = {} int fd_tun, fd_tmp; char buf[4] = {}; fd_tun = openat(AT_FDCWD, "/dev/net/tun", O_WRONLY, 0); ifr.ifr_flags = IFF_TUN | IFF_NAPI | IFF_MULTI_QUEUE; ioctl(fd_tun, TUNSETIFF, &ifr); ifr.ifr_flags = IFF_DETACH_QUEUE; ioctl(fd_tun, TUNSETQUEUE, &ifr); fd_tmp = socket(AF_PACKET, SOCK_PACKET, 0); ifr.ifr_flags = IFF_UP; ioctl(fd_tmp, SIOCSIFFLAGS, &ifr); write(fd_tun, buf, sizeof(buf)); close(fd_tun); If we enable NAPI and multi-queue on a TUN device, we can put skb into tfile->sk.sk_write_queue after the queue is detached. We should prevent it by checking tfile->detached before queuing skb. Note this must be done under tfile->sk.sk_write_queue.lock because write() and ioctl(IFF_DETACH_QUEUE) can run concurrently. Otherwise, there would be a small race window: write() ioctl(IFF_DETACH_QUEUE) `- tun_get_user `- __tun_detach |- if (tfile->detached) |- tun_disable_queue | `-> false | `- tfile->detached = tun | `- tun_queue_purge |- spin_lock_bh(&queue->lock) `- __skb_queue_tail(queue, skb) Another solution is to call tun_queue_purge() when closing and reattaching the detached queue, but it could paper over another problems. Also, we do the same kind of test for IFF_NAPI_FRAGS. [0]: unreferenced object 0xffff88801edbc800 (size 2048): comm "syz-executor.1", pid 33269, jiffies 4295743834 (age 18.756s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace: [<000000008c16ea3d>] __do_kmalloc_node mm/slab_common.c:965 [inline] [<000000008c16ea3d>] __kmalloc+0x4a/0x130 mm/slab_common.c:979 [<000000003addde56>] kmalloc include/linux/slab.h:563 [inline] [<000000003addde56>] sk_prot_alloc+0xef/0x1b0 net/core/sock.c:2035 [<000000003e20621f>] sk_alloc+0x36/0x2f0 net/core/sock.c:2088 [<0000000028e43843>] tun_chr_open+0x3d/0x190 drivers/net/tun.c:3438 [<000000001b0f1f28>] misc_open+0x1a6/0x1f0 drivers/char/misc.c:165 [<000000004376f706>] chrdev_open+0x111/0x300 fs/char_dev.c:414 [<00000000614d379f>] do_dentry_open+0x2f9/0x750 fs/open.c:920 [<000000008eb24774>] do_open fs/namei.c:3636 [inline] [<000000008eb24774>] path_openat+0x143f/0x1a30 fs/namei.c:3791 [<00000000955077b5>] do_filp_open+0xce/0x1c0 fs/namei.c:3818 [<00000000b78973b0>] do_sys_openat2+0xf0/0x260 fs/open.c:1356 [<00000000057be699>] do_sys_open fs/open.c:1372 [inline] [<00000000057be699>] __do_sys_openat fs/open.c:1388 [inline] [<00000000057be699>] __se_sys_openat fs/open.c:1383 [inline] [<00000000057be699>] __x64_sys_openat+0x83/0xf0 fs/open.c:1383 [<00000000a7d2182d>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<00000000a7d2182d>] do_syscall_64+0x3c/0x90 arch/x86/entry/common.c:80 [<000000004cc4e8c4>] entry_SYSCALL_64_after_hwframe+0x72/0xdc unreferenced object 0xffff88802f671700 (size 240): comm "syz-executor.1", pid 33269, jiffies 4295743854 (age 18.736s) hex dump (first 32 bytes): 68 c9 db 1e 80 88 ff ff 68 c9 db 1e 80 88 ff ff h.......h....... 00 c0 7b 2f 80 88 ff ff 00 c8 db 1e 80 88 ff ff ..{/............ backtrace: [<00000000e9d9fdb6>] __alloc_skb+0x223/0x250 net/core/skbuff.c:644 [<000000002c3e4e0b>] alloc_skb include/linux/skbuff.h:1288 [inline] [<000000002c3e4e0b>] alloc_skb_with_frags+0x6f/0x350 net/core/skbuff.c:6378 [<00000000825f98d7>] sock_alloc_send_pskb+0x3ac/0x3e0 net/core/sock.c:2729 [<00000000e9eb3df3>] tun_alloc_skb drivers/net/tun.c:1529 [inline] [<00000000e9eb3df3>] tun_get_user+0x5e1/0x1f90 drivers/net/tun.c:1841 [<0000000053096912>] tun_chr_write_iter+0xac/0x120 drivers/net/tun.c:2035 [<00000000b9282ae0>] call_write_iter include/linux/fs.h:1868 [inline] [<00000000b9282ae0>] new_sync_write fs/read_write.c:491 [inline] [<00000000b9282ae0>] vfs_write+0x40f/0x530 fs/read_write.c:584 [<00000000524566e4>] ksys_write+0xa1/0x170 fs/read_write.c:637 [<00000000a7d2182d>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<00000000a7d2182d>] do_syscall_64+0x3c/0x90 arch/x86/entry/common.c:80 [<000000004cc4e8c4>] entry_SYSCALL_64_after_hwframe+0x72/0xdc Fixes: cde8b15f1aab ("tuntap: add ioctl to attach or detach a file form tuntap device") Reported-by: syzkaller <syzkaller@googlegroups.com> Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-05-17Merge patch series "can: kvaser_pciefd: Bug fixes"Marc Kleine-Budde
Jimmy Assarsson <extja@kvaser.com> says: This patch series contains various bug fixes for the kvaser_pciefd driver. Link: https://lore.kernel.org/r/20230516134318.104279-1-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-17can: kvaser_pciefd: Disable interrupts in probe error pathJimmy Assarsson
Disable interrupts in error path of probe function. Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices") Cc: stable@vger.kernel.org Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://lore.kernel.org/r/20230516134318.104279-7-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-17can: kvaser_pciefd: Do not send EFLUSH command on TFD interruptJimmy Assarsson
Under certain circumstances we send two EFLUSH commands, resulting in two EFLUSH ack packets, while only expecting a single EFLUSH ack. This can cause the driver Tx flush completion to get out of sync. To avoid this problem, don't enable the "Transmit buffer flush done" (TFD) interrupt and remove the code handling it. Now we only send EFLUSH command after receiving status packet with "Init detected" (IDET) bit set. Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices") Cc: stable@vger.kernel.org Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://lore.kernel.org/r/20230516134318.104279-6-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-17can: kvaser_pciefd: Empty SRB buffer in probeJimmy Assarsson
Empty the "Shared receive buffer" (SRB) in probe, to assure we start in a known state, and don't process any irrelevant packets. Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices") Cc: stable@vger.kernel.org Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://lore.kernel.org/r/20230516134318.104279-5-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-17can: kvaser_pciefd: Call request_irq() before enabling interruptsJimmy Assarsson
Make sure the interrupt handler is registered before enabling interrupts. Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices") Cc: stable@vger.kernel.org Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://lore.kernel.org/r/20230516134318.104279-4-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-17can: kvaser_pciefd: Clear listen-only bit if not explicitly requestedJimmy Assarsson
The listen-only bit was never cleared, causing the controller to always use listen-only mode, if previously set. Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices") Cc: stable@vger.kernel.org Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://lore.kernel.org/r/20230516134318.104279-3-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-17can: kvaser_pciefd: Set CAN_STATE_STOPPED in kvaser_pciefd_stop()Jimmy Assarsson
Set can.state to CAN_STATE_STOPPED in kvaser_pciefd_stop(). Without this fix, wrong CAN state was repported after the interface was brought down. Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices") Cc: stable@vger.kernel.org Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://lore.kernel.org/r/20230516134318.104279-2-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-17wifi: b43: fix incorrect __packed annotationArnd Bergmann
clang warns about an unpacked structure inside of a packed one: drivers/net/wireless/broadcom/b43/b43.h:654:4: error: field data within 'struct b43_iv' is less aligned than 'union (unnamed union at /home/arnd/arm-soc/drivers/net/wireless/broadcom/b43/b43.h:651:2)' and is usually due to 'struct b43_iv' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access] The problem here is that the anonymous union has the default alignment from its members, apparently because the original author mixed up the placement of the __packed attribute by placing it next to the struct member rather than the union definition. As the struct itself is also marked as __packed, there is no need to mark its members, so just move the annotation to the inner type instead. As Michael noted, the same problem is present in b43legacy, so change both at the same time. Acked-by: Michael Büsch <m@bues.ch> Reported-by: kernel test robot <lkp@intel.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Link: https://lore.kernel.org/oe-kbuild-all/202305160749.ay1HAoyP-lkp@intel.com/ Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230516183442.536589-1-arnd@kernel.org
2023-05-17wifi: rtw88: sdio: Always use two consecutive bytes for word operationsMartin Blumenstingl
The Allwinner sunxi-mmc controller cannot handle word (16 bit) transfers. So and sdio_{read,write}w fails with messages like the following example using an RTL8822BS (but the same problems were also observed with RTL8822CS and RTL8723DS chips): rtw_8822bs mmc1:0001:1: Firmware version 27.2.0, H2C version 13 sunxi-mmc 4021000.mmc: unaligned scatterlist: os f80 length 2 sunxi-mmc 4021000.mmc: map DMA failed rtw_8822bs mmc1:0001:1: sdio read16 failed (0x10230): -22 Use two consecutive single byte accesses for word operations instead. It turns out that upon closer inspection this is also what the vendor driver does, even though it does have support for sdio_{read,write}w. So we can conclude that the rtw88 chips do support word access but only on SDIO controllers that also support it. Since there's no way to detect if the controller supports word access or not the rtw88 sdio driver switches to the easiest approach: avoiding word access. Reported-by: Larry Finger <Larry.Finger@lwfinger.net> Closes: https://lore.kernel.org/linux-wireless/527585e5-9cdd-66ed-c3af-6da162f4b720@lwfinger.net/ Reported-by: Rudi Heitbaum <rudi@heitbaum.com> Link: https://github.com/LibreELEC/LibreELEC.tv/pull/7837#issue-1708469467 Fixes: 65371a3f14e7 ("wifi: rtw88: sdio: Add HCI implementation for SDIO based chipsets") Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230515195043.572375-1-martin.blumenstingl@googlemail.com
2023-05-16Merge tag 'ipsec-2023-05-16' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec Steffen Klassert says: ==================== pull request (net): ipsec 2023-05-16 1) Don't check the policy default if we have an allow policy. Fix from Sabrina Dubroca. 2) Fix netdevice refount usage on offload. From Leon Romanovsky. 3) Use netdev_put instead of dev_puti to correctly release the netdev on failure in xfrm_dev_policy_add. From Leon Romanovsky. 4) Revert "Fix XFRM-I support for nested ESP tunnels" This broke Netfilter policy matching. From Martin Willi. 5) Reject optional tunnel/BEET mode templates in outbound policies on netlink and pfkey sockets. From Tobias Brunner. 6) Check if_id in inbound policy/secpath match to make it symetric to the outbound codepath. From Benedict Wong. * tag 'ipsec-2023-05-16' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec: xfrm: Check if_id in inbound policy/secpath match af_key: Reject optional tunnel/BEET mode templates in outbound policies xfrm: Reject optional tunnel/BEET mode templates in outbound policies Revert "Fix XFRM-I support for nested ESP tunnels" xfrm: Fix leak of dev tracker xfrm: release all offloaded policy memory xfrm: don't check the default policy if the policy allows the packet ==================== Link: https://lore.kernel.org/r/20230516052405.2677554-1-steffen.klassert@secunet.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-16Merge tag 'linux-can-fixes-for-6.4-20230515' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine-Budde says: ==================== pull-request: can 2023-05-15 The first 2 patches are by Oliver Hartkopp and allow the MSG_CMSG_COMPAT flag for isotp and j1939. The next patch is by Oliver Hartkopp, too and adds missing CAN XL support in can_put_echo_skb(). Geert Uytterhoeven's patch let's the bxcan driver depend on ARCH_STM32. The last 5 patches are from Dario Binacchi and also affect the bxcan driver. The bxcan driver hit mainline with v6.4-rc1 and was originally written for IP cores containing 2 CAN interfaces with shared resources. Dario's series updates the DT bindings and driver to support IP cores with a single CAN interface instance as well as adding the bxcan to the stm32f746's device tree. * tag 'linux-can-fixes-for-6.4-20230515' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can: ARM: dts: stm32: add CAN support on stm32f746 can: bxcan: add support for single peripheral configuration ARM: dts: stm32: add pin map for CAN controller on stm32f7 ARM: dts: stm32f429: put can2 in secondary mode dt-bindings: net: can: add "st,can-secondary" property can: CAN_BXCAN should depend on ARCH_STM32 can: dev: fix missing CAN XL support in can_put_echo_skb() can: j1939: recvmsg(): allow MSG_CMSG_COMPAT flag can: isotp: recvmsg(): allow MSG_CMSG_COMPAT flag ==================== Link: https://lore.kernel.org/r/20230515204722.1000957-1-mkl@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-16devlink: Fix crash with CONFIG_NET_NS=nIdo Schimmel
'__net_initdata' becomes a no-op with CONFIG_NET_NS=y, but when this option is disabled it becomes '__initdata', which means the data can be freed after the initialization phase. This annotation is obviously incorrect for the devlink net device notifier block which is still registered after the initialization phase [1]. Fix this crash by removing the '__net_initdata' annotation. [1] general protection fault, probably for non-canonical address 0xcccccccccccccccc: 0000 [#1] PREEMPT SMP CPU: 3 PID: 117 Comm: (udev-worker) Not tainted 6.4.0-rc1-custom-gdf0acdc59b09 #64 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc37 04/01/2014 RIP: 0010:notifier_call_chain+0x58/0xc0 [...] Call Trace: <TASK> dev_set_mac_address+0x85/0x120 dev_set_mac_address_user+0x30/0x50 do_setlink+0x219/0x1270 rtnl_setlink+0xf7/0x1a0 rtnetlink_rcv_msg+0x142/0x390 netlink_rcv_skb+0x58/0x100 netlink_unicast+0x188/0x270 netlink_sendmsg+0x214/0x470 __sys_sendto+0x12f/0x1a0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x38/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Fixes: e93c9378e33f ("devlink: change per-devlink netdev notifier to static one") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Closes: https://lore.kernel.org/netdev/600ddf9e-589a-2aa0-7b69-a438f833ca10@samsung.com/ Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230515162925.1144416-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-16samples/bpf: Drop unnecessary fallthroughAndrii Nakryiko
__fallthrough is now not supported. Instead of renaming it to now-canonical ([0]) fallthrough pseudo-keyword, just get rid of it and equate 'h' case to default case, as both emit usage information and succeed. [0] https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Yonghong Song <yhs@fb.com> Link: https://lore.kernel.org/bpf/20230516001718.317177-1-andrii@kernel.org
2023-05-16mac80211_hwsim: fix memory leak in hwsim_new_radio_nlZhengchao Shao
When parse_pmsr_capa failed in hwsim_new_radio_nl, the memory resources applied for by pmsr_capa are not released. Add release processing to the incorrect path. Fixes: 92d13386ec55 ("mac80211_hwsim: add PMSR capability support") Reported-by: syzbot+904ce6fbb38532d9795c@syzkaller.appspotmail.com Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230515092227.2691437-1-shaozhengchao@huawei.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-05-16wifi: iwlwifi: mvm: Add locking to the rate read flowAriel Malamud
The rs_drv_get_rate flow reads the lq_sta to return the optimal rate for tx frames. This read flow is not protected thereby leaving a small window, a few instructions wide, open to contention by an asynchronous rate update. Indeed this race condition was hit and the update occurred in the middle of the read. Fix this by locking the lq_sta struct during read. Signed-off-by: Ariel Malamud <ariel.malamud@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230514120631.b52c9ed5c379.I15290b78e0d966c1b68278263776ca9de841d5fe@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-05-16wifi: iwlwifi: Don't use valid_links to iterate sta linksMiri Korenblit
This bitmap equals to zero when in a non-MLO mode, and then we won't be iterating on any link. Use for_each_sta_active_link() instead, as it handles also the case of non-MLO mode. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230514120631.f32a8c08730a.Ib02248cd0b7f2bc885f91005c3c110dd027f9dcd@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-05-16wifi: iwlwifi: mvm: don't trust firmware n_channelsJohannes Berg
If the firmware sends us a corrupted MCC response with n_channels much larger than the command response can be, we might copy far too much (uninitialized) memory and even crash if the n_channels is large enough to make it run out of the one page allocated for the FW response. Fix that by checking the lengths. Doing a < comparison would be sufficient, but the firmware should be doing it correctly, so check more strictly. Fixes: dcaf9f5ecb6f ("iwlwifi: mvm: add MCC update FW API") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230514120631.d7b233139eb4.I51fd319df8e9d41881fc8450e83d78049518a79a@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-05-16wifi: iwlwifi: mvm: fix OEM's name in the tas approved listAlon Giladi
Fix a spelling mistake. Fixes: 2856f623ce48 ("iwlwifi: mvm: Add list of OEMs allowed to use TAS") Signed-off-by: Alon Giladi <alon.giladi@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230514120631.4090de6d1878.If9391ef6da78f1b2cc5eb6cb8f6965816bb7a7f5@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-05-16wifi: iwlwifi: fix OEM's name in the ppag approved listAlon Giladi
Fix a spelling mistake. Fixes: e8e10a37c51c ("iwlwifi: acpi: move ppag code from mvm to fw/acpi") Signed-off-by: Alon Giladi <alon.giladi@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230514120631.fdd07f36a8bf.I223e5fb16ab5c95d504c3fdaffd0bd70affad1c2@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-05-16wifi: iwlwifi: mvm: fix initialization of a return valueMukesh Sisodiya
In iwl_mvm_mld_update_sta(), if the flow doesn't enter for_each_sta_active_link(), the default value is returned. Set this default to -EINVAL instead of 0 to better reflect this. Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230514120631.98b7e3aacf0b.I2fc274dd7e374ef7fac8e26d71c9cd73323da665@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-05-16wifi: iwlwifi: mvm: fix access to fw_id_to_mac_idGregory Greenman
RCU protected fw_id_to_mac_id can be initialized with either an error code or NULL. Thus, after dereferencing need to check the value with IS_ERR_OR_NULL() and not only that it is not NULL. Fix it. Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230514120631.ec5f2880e81c.Ifa8c0f451df2835bde800f5c3670cc46238a3bd8@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-05-16wifi: iwlwifi: fw: fix DBGI dumpJohannes Berg
The DBGI dump is (unsurprisingly) of type DBGI, not SRAM. This leads to bad register accesses because the union is built differently, there's no allocation ID, and thus the allocation ID ends up being 0x8000. Note that this was already wrong for DRAM vs. SMEM since they use different parts of the union, but the allocation ID is at the same place, so it worked. Fix all of this but set the allocation ID in a way that the offset calculation ends up without any offset. Fixes: 34bc27783a31 ("iwlwifi: yoyo: fix DBGI_SRAM ini dump header.") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230514120631.19a302ae4c65.I12272599f7c1930666157b9d5e7f81fe9ec4c421@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-05-16wifi: iwlwifi: mvm: fix number of concurrent link checksJohannes Berg
The concurrent link checks need to correctly differentiate between AP and non-AP, fix that. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230514120631.992b2f981ef6.I7d386c19354e9be39c4822f436dd22c93422b660@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-05-16wifi: iwlwifi: mvm: fix cancel_delayed_work_sync() deadlockJohannes Berg
Lockdep points out that we can deadlock here by calling cancel_delayed_work_sync() because that might be already running and gotten interrupted by the NAPI soft-IRQ. Even just calling something that can sleep is wrong in this context though. Luckily, it doesn't even really matter since the things we need to do are idempotent, so just drop the _sync(). Fixes: e5d153ec54f0 ("iwlwifi: mvm: fix CSA AP side") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230514120631.b1813c823b4d.I9d20cc06d24fa40b6774d3dd95ea5e2bf8dd015b@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-05-16wifi: iwlwifi: mvm: don't double-init spinlockJohannes Berg
We don't need to (and shouldn't) initialize the spinlock during HW restart that was already initialized, so move that into the correct if block. Since then we have two consecutive if statements with the same (though inverted) condition, unify those as well. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230514120631.221c22cfdf4e.I2e30113ef4bd8cb5bd9e1a69e52a95671914961c@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-05-16wifi: iwlwifi: mvm: always free dup_dataJohannes Berg
There are some assertions in the STA removal code that can fail, and in that case we may leak memory since we skip the freeing. Fix this by freeing the dup_data earlier in the function, we already have a check for when we free the station, and this we don't need to do it with and without MLD API, so it's a win all around. Fixes: a571f5f635ef ("iwlwifi: mvm: add duplicate packet detection per rx queue") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230514120631.173938681d72.Iff4b55fc52943825d6e3e28d78a24b155ea5cd22@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-05-16wifi: mac80211: recalc chanctx mindef before assigningJohannes Berg
When we allocate a new channel context, or find an existing one that is compatible, we currently assign it to a link before its mindef is updated. This leads to strange situations, especially in link switching where you switch to an 80 MHz link and expect it to be active immediately, but the mindef is still configured to 20 MHz while assigning. Also, it's strange that the chandef passed to the assign method's argument is wider than the one in the context. Fix this by calculating the mindef with the new link considered before calling the driver. In particular, this fixes an iwlwifi problem during link switch where the firmware would assert because the (link) station that was added for the AP is configured to transmit at a bandwidth that's wider than the channel context that it's configured on. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230504134511.828474-5-gregory.greenman@intel.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-05-16wifi: mac80211: consider reserved chanctx for mindefJohannes Berg
When a chanctx is reserved for a new vif and we recalculate the minimal definition for it, we need to consider the new interface it's being reserved for before we assign it, so it can be used directly with the correct min channel width. Fix the code to - optionally - consider that, and use that option just before doing the reassignment. Also, when considering channel context reservations, we should only consider the one link we're currently working with. Change the boolean argument to a link pointer to do that. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230504134511.828474-4-gregory.greenman@intel.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-05-16wifi: mac80211: simplify chanctx allocationJohannes Berg
There's no need to call ieee80211_recalc_chanctx_min_def() since it cannot and won't call the driver anyway; just use _ieee80211_recalc_chanctx_min_def() instead. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230504134511.828474-3-gregory.greenman@intel.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-05-16wifi: mac80211: Abort running color change when stopping the APMichael Lee
When stopping the AP, there might be a color change in progress. It should be deactivated here, or the driver might later finalize a color change on a stopped AP. Fixes: 5f9404abdf2a (mac80211: add support for BSS color change) Signed-off-by: Michael Lee <michael-cy.lee@mediatek.com> Link: https://lore.kernel.org/r/20230504080441.22958-1-michael-cy.lee@mediatek.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-05-16wifi: mac80211: fix min center freq offset tracingJohannes Berg
We need to set the correct trace variable, otherwise we're overwriting something else instead and the right one that we print later is not initialized. Fixes: b6011960f392 ("mac80211: handle channel frequency offset") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230504134511.828474-2-gregory.greenman@intel.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-05-16wifi: iwlwifi: mvm: rfi: disable RFI featureGregory Greenman
This feature depends on a platform bugfix. Until we have a mechanism that can verify a platform has the required bugfix, disable RFI. Fixes: ef3ed33dfc8f ("wifi: iwlwifi: bump FW API to 77 for AX devices") Reported-by: Jeff Chua <jeff.chua.linux@gmail.com> Link: https://lore.kernel.org/linux-wireless/CAAJw_ZvZdFpw9W2Hisc9c2BAFbYAnQuaFFaFG6N7qPUP2fOL_w@mail.gmail.com/ Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-05-16wifi: mac80211: Fix puncturing bitmap handling in __ieee80211_csa_finalize()Christophe JAILLET
'changed' can be OR'ed with BSS_CHANGED_EHT_PUNCTURING which is larger than an u32. So, turn 'changed' into an u64 and update ieee80211_set_after_csa_beacon() accordingly. In the commit in Fixes, only ieee80211_start_ap() was updated. Fixes: 2cc25e4b2a04 ("wifi: mac80211: configure puncturing bitmap") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/e84a3f80fe536787f7a2c7180507efc36cd14f95.1682358088.git.christophe.jaillet@wanadoo.fr Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-05-16wifi: mac80211: fortify the spinlock against deadlock by interruptMirsad Goran Todorovac
In the function ieee80211_tx_dequeue() there is a particular locking sequence: begin: spin_lock(&local->queue_stop_reason_lock); q_stopped = local->queue_stop_reasons[q]; spin_unlock(&local->queue_stop_reason_lock); However small the chance (increased by ftracetest), an asynchronous interrupt can occur in between of spin_lock() and spin_unlock(), and the interrupt routine will attempt to lock the same &local->queue_stop_reason_lock again. This will cause a costly reset of the CPU and the wifi device or an altogether hang in the single CPU and single core scenario. The only remaining spin_lock(&local->queue_stop_reason_lock) that did not disable interrupts was patched, which should prevent any deadlocks on the same CPU/core and the same wifi device. This is the probable trace of the deadlock: kernel: ================================ kernel: WARNING: inconsistent lock state kernel: 6.3.0-rc6-mt-20230401-00001-gf86822a1170f #4 Tainted: G W kernel: -------------------------------- kernel: inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. kernel: kworker/5:0/25656 [HC0[0]:SC0[0]:HE1:SE1] takes: kernel: ffff9d6190779478 (&local->queue_stop_reason_lock){+.?.}-{2:2}, at: return_to_handler+0x0/0x40 kernel: {IN-SOFTIRQ-W} state was registered at: kernel: lock_acquire+0xc7/0x2d0 kernel: _raw_spin_lock+0x36/0x50 kernel: ieee80211_tx_dequeue+0xb4/0x1330 [mac80211] kernel: iwl_mvm_mac_itxq_xmit+0xae/0x210 [iwlmvm] kernel: iwl_mvm_mac_wake_tx_queue+0x2d/0xd0 [iwlmvm] kernel: ieee80211_queue_skb+0x450/0x730 [mac80211] kernel: __ieee80211_xmit_fast.constprop.66+0x834/0xa50 [mac80211] kernel: __ieee80211_subif_start_xmit+0x217/0x530 [mac80211] kernel: ieee80211_subif_start_xmit+0x60/0x580 [mac80211] kernel: dev_hard_start_xmit+0xb5/0x260 kernel: __dev_queue_xmit+0xdbe/0x1200 kernel: neigh_resolve_output+0x166/0x260 kernel: ip_finish_output2+0x216/0xb80 kernel: __ip_finish_output+0x2a4/0x4d0 kernel: ip_finish_output+0x2d/0xd0 kernel: ip_output+0x82/0x2b0 kernel: ip_local_out+0xec/0x110 kernel: igmpv3_sendpack+0x5c/0x90 kernel: igmp_ifc_timer_expire+0x26e/0x4e0 kernel: call_timer_fn+0xa5/0x230 kernel: run_timer_softirq+0x27f/0x550 kernel: __do_softirq+0xb4/0x3a4 kernel: irq_exit_rcu+0x9b/0xc0 kernel: sysvec_apic_timer_interrupt+0x80/0xa0 kernel: asm_sysvec_apic_timer_interrupt+0x1f/0x30 kernel: _raw_spin_unlock_irqrestore+0x3f/0x70 kernel: free_to_partial_list+0x3d6/0x590 kernel: __slab_free+0x1b7/0x310 kernel: kmem_cache_free+0x52d/0x550 kernel: putname+0x5d/0x70 kernel: do_sys_openat2+0x1d7/0x310 kernel: do_sys_open+0x51/0x80 kernel: __x64_sys_openat+0x24/0x30 kernel: do_syscall_64+0x5c/0x90 kernel: entry_SYSCALL_64_after_hwframe+0x72/0xdc kernel: irq event stamp: 5120729 kernel: hardirqs last enabled at (5120729): [<ffffffff9d149936>] trace_graph_return+0xd6/0x120 kernel: hardirqs last disabled at (5120728): [<ffffffff9d149950>] trace_graph_return+0xf0/0x120 kernel: softirqs last enabled at (5069900): [<ffffffff9cf65b60>] return_to_handler+0x0/0x40 kernel: softirqs last disabled at (5067555): [<ffffffff9cf65b60>] return_to_handler+0x0/0x40 kernel: other info that might help us debug this: kernel: Possible unsafe locking scenario: kernel: CPU0 kernel: ---- kernel: lock(&local->queue_stop_reason_lock); kernel: <Interrupt> kernel: lock(&local->queue_stop_reason_lock); kernel: *** DEADLOCK *** kernel: 8 locks held by kworker/5:0/25656: kernel: #0: ffff9d618009d138 ((wq_completion)events_freezable){+.+.}-{0:0}, at: process_one_work+0x1ca/0x530 kernel: #1: ffffb1ef4637fe68 ((work_completion)(&local->restart_work)){+.+.}-{0:0}, at: process_one_work+0x1ce/0x530 kernel: #2: ffffffff9f166548 (rtnl_mutex){+.+.}-{3:3}, at: return_to_handler+0x0/0x40 kernel: #3: ffff9d6190778728 (&rdev->wiphy.mtx){+.+.}-{3:3}, at: return_to_handler+0x0/0x40 kernel: #4: ffff9d619077b480 (&mvm->mutex){+.+.}-{3:3}, at: return_to_handler+0x0/0x40 kernel: #5: ffff9d61907bacd8 (&trans_pcie->mutex){+.+.}-{3:3}, at: return_to_handler+0x0/0x40 kernel: #6: ffffffff9ef9cda0 (rcu_read_lock){....}-{1:2}, at: iwl_mvm_queue_state_change+0x59/0x3a0 [iwlmvm] kernel: #7: ffffffff9ef9cda0 (rcu_read_lock){....}-{1:2}, at: iwl_mvm_mac_itxq_xmit+0x42/0x210 [iwlmvm] kernel: stack backtrace: kernel: CPU: 5 PID: 25656 Comm: kworker/5:0 Tainted: G W 6.3.0-rc6-mt-20230401-00001-gf86822a1170f #4 kernel: Hardware name: LENOVO 82H8/LNVNB161216, BIOS GGCN51WW 11/16/2022 kernel: Workqueue: events_freezable ieee80211_restart_work [mac80211] kernel: Call Trace: kernel: <TASK> kernel: ? ftrace_regs_caller_end+0x66/0x66 kernel: dump_stack_lvl+0x5f/0xa0 kernel: dump_stack+0x14/0x20 kernel: print_usage_bug.part.46+0x208/0x2a0 kernel: mark_lock.part.47+0x605/0x630 kernel: ? sched_clock+0xd/0x20 kernel: ? trace_clock_local+0x14/0x30 kernel: ? __rb_reserve_next+0x5f/0x490 kernel: ? _raw_spin_lock+0x1b/0x50 kernel: __lock_acquire+0x464/0x1990 kernel: ? mark_held_locks+0x4e/0x80 kernel: lock_acquire+0xc7/0x2d0 kernel: ? ftrace_regs_caller_end+0x66/0x66 kernel: ? ftrace_return_to_handler+0x8b/0x100 kernel: ? preempt_count_add+0x4/0x70 kernel: _raw_spin_lock+0x36/0x50 kernel: ? ftrace_regs_caller_end+0x66/0x66 kernel: ? ftrace_regs_caller_end+0x66/0x66 kernel: ieee80211_tx_dequeue+0xb4/0x1330 [mac80211] kernel: ? prepare_ftrace_return+0xc5/0x190 kernel: ? ftrace_graph_func+0x16/0x20 kernel: ? 0xffffffffc02ab0b1 kernel: ? lock_acquire+0xc7/0x2d0 kernel: ? iwl_mvm_mac_itxq_xmit+0x42/0x210 [iwlmvm] kernel: ? ieee80211_tx_dequeue+0x9/0x1330 [mac80211] kernel: ? __rcu_read_lock+0x4/0x40 kernel: ? ftrace_regs_caller_end+0x66/0x66 kernel: iwl_mvm_mac_itxq_xmit+0xae/0x210 [iwlmvm] kernel: ? ftrace_regs_caller_end+0x66/0x66 kernel: iwl_mvm_queue_state_change+0x311/0x3a0 [iwlmvm] kernel: ? ftrace_regs_caller_end+0x66/0x66 kernel: iwl_mvm_wake_sw_queue+0x17/0x20 [iwlmvm] kernel: ? ftrace_regs_caller_end+0x66/0x66 kernel: iwl_txq_gen2_unmap+0x1c9/0x1f0 [iwlwifi] kernel: ? ftrace_regs_caller_end+0x66/0x66 kernel: iwl_txq_gen2_free+0x55/0x130 [iwlwifi] kernel: ? ftrace_regs_caller_end+0x66/0x66 kernel: iwl_txq_gen2_tx_free+0x63/0x80 [iwlwifi] kernel: ? ftrace_regs_caller_end+0x66/0x66 kernel: _iwl_trans_pcie_gen2_stop_device+0x3f3/0x5b0 [iwlwifi] kernel: ? _iwl_trans_pcie_gen2_stop_device+0x9/0x5b0 [iwlwifi] kernel: ? mutex_lock_nested+0x4/0x30 kernel: ? ftrace_regs_caller_end+0x66/0x66 kernel: iwl_trans_pcie_gen2_stop_device+0x5f/0x90 [iwlwifi] kernel: ? ftrace_regs_caller_end+0x66/0x66 kernel: iwl_mvm_stop_device+0x78/0xd0 [iwlmvm] kernel: ? ftrace_regs_caller_end+0x66/0x66 kernel: __iwl_mvm_mac_start+0x114/0x210 [iwlmvm] kernel: ? ftrace_regs_caller_end+0x66/0x66 kernel: iwl_mvm_mac_start+0x76/0x150 [iwlmvm] kernel: ? ftrace_regs_caller_end+0x66/0x66 kernel: drv_start+0x79/0x180 [mac80211] kernel: ? ftrace_regs_caller_end+0x66/0x66 kernel: ieee80211_reconfig+0x1523/0x1ce0 [mac80211] kernel: ? synchronize_net+0x4/0x50 kernel: ? ftrace_regs_caller_end+0x66/0x66 kernel: ieee80211_restart_work+0x108/0x170 [mac80211] kernel: ? ftrace_regs_caller_end+0x66/0x66 kernel: process_one_work+0x250/0x530 kernel: ? ftrace_regs_caller_end+0x66/0x66 kernel: worker_thread+0x48/0x3a0 kernel: ? __pfx_worker_thread+0x10/0x10 kernel: kthread+0x10f/0x140 kernel: ? __pfx_kthread+0x10/0x10 kernel: ret_from_fork+0x29/0x50 kernel: </TASK> Fixes: 4444bc2116ae ("wifi: mac80211: Proper mark iTXQs for resumption") Link: https://lore.kernel.org/all/1f58a0d1-d2b9-d851-73c3-93fcc607501c@alu.unizg.hr/ Reported-by: Mirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr> Cc: Gregory Greenman <gregory.greenman@intel.com> Cc: Johannes Berg <johannes.berg@intel.com> Link: https://lore.kernel.org/all/cdc80531-f25f-6f9d-b15f-25e16130b53a@alu.unizg.hr/ 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: Leon Romanovsky <leon@kernel.org> Cc: Alexander Wetzel <alexander@wetzel-home.de> Signed-off-by: Mirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Reviewed-by: tag, or it goes automatically? Link: https://lore.kernel.org/r/20230425164005.25272-1-mirsad.todorovac@alu.unizg.hr Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-05-16wifi: cfg80211: Drop entries with invalid BSSIDs in RNRIlan Peer
Ignore AP information for entries that include an invalid BSSID in the TBTT information field, e.g., all zeros BSSIDs. Fixes: c8cb5b854b40 ("nl80211/cfg80211: support 6 GHz scanning") Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230424103224.5e65d04d1448.Ic10c8577ae4a85272c407106c9d0a2ecb5372743@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-05-16iavf: send VLAN offloading caps once after VFRAhmed Zaki
When the user disables rxvlan offloading and then changes the number of channels, all VLAN ports are unable to receive traffic. Changing the number of channels triggers a VFR reset. During re-init, when VIRTCHNL_OP_GET_OFFLOAD_VLAN_V2_CAPS is received, we do: 1 - set the IAVF_FLAG_SETUP_NETDEV_FEATURES flag 2 - call iavf_set_vlan_offload_features(adapter, 0, netdev->features); The second step sends to the PF the __default__ features, in this case aq_required |= IAVF_FLAG_AQ_ENABLE_CTAG_VLAN_STRIPPING While the first step forces the watchdog task to call netdev_update_features() -> iavf_set_features() -> iavf_set_vlan_offload_features(adapter, netdev->features, features). Since the user disabled the "rxvlan", this sets: aq_required |= IAVF_FLAG_AQ_DISABLE_CTAG_VLAN_STRIPPING When we start processing the AQ commands, both flags are enabled. Since we process DISABLE_XTAG first then ENABLE_XTAG, this results in the PF enabling the rxvlan offload. This breaks all communications on the VLAN net devices. Fix by removing the call to iavf_set_vlan_offload_features() (second step). Calling netdev_update_features() from watchdog task is enough for both init and reset paths. Fixes: 7598f4b40bd6 ("iavf: Move netdev_update_features() into watchdog task") Signed-off-by: Ahmed Zaki <ahmed.zaki@intel.com> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-05-16ice: Fix ice VF reset during iavf initializationDawid Wesierski
Fix the current implementation that causes ice_trigger_vf_reset() to start resetting the VF even when the VF-NIC is still initializing. When we reset NIC with ice driver it can interfere with iavf-vf initialization e.g. during consecutive resets induced by ice iavf ice | | |<-----------------| | ice resets vf iavf | reset | start | |<-----------------| | ice resets vf | causing iavf | initialization | error | | iavf reset end This leads to a series of -53 errors (failed to init adminq) from the IAVF. Change the state of the vf_state field to be not active when the IAVF is still initializing. Make sure to wait until receiving the message on the message box to ensure that the vf is ready and initializded. In simple terms we use the ACTIVE flag to make sure that the ice driver knows if the iavf is ready for another reset iavf ice | | | | |<------------- ice resets vf iavf vf_state != ACTIVE reset | start | | | | | iavf | reset-------> vf_state == ACTIVE end ice resets vf | | | | Fixes: c54d209c78b8 ("ice: Wait for VF to be reset/ready before configuration") Signed-off-by: Dawid Wesierski <dawidx.wesierski@intel.com> Signed-off-by: Kamil Maziarz <kamil.maziarz@intel.com> Acked-by: Jacob Keller <Jacob.e.keller@intel.com> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-05-16ice: Fix stats after PF resetAhmed Zaki
After a core PF reset, the VFs were showing wrong Rx/Tx stats. This is a regression in commit 6624e780a577 ("ice: split ice_vsi_setup into smaller functions") caused by missing to set "stat_offsets_loaded = false" in the ice_vsi_rebuild() path. Fixes: 6624e780a577 ("ice: split ice_vsi_setup into smaller functions") Signed-off-by: Ahmed Zaki <ahmed.zaki@intel.com> Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2023-05-16net: bcmgenet: Restore phy_stop() depending upon suspend/closeFlorian Fainelli
Removing the phy_stop() from bcmgenet_netif_stop() ended up causing warnings from the PHY library that phy_start() is called from the RUNNING state since we are no longer stopping the PHY state machine during bcmgenet_suspend(). Restore the call to phy_stop() but make it conditional on being called from the close or suspend path. Fixes: c96e731c93ff ("net: bcmgenet: connect and disconnect from the PHY state machine") Fixes: 93e0401e0fc0 ("net: bcmgenet: Remove phy_stop() from bcmgenet_netif_stop()") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Link: https://lore.kernel.org/r/20230515025608.2587012-1-f.fainelli@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-05-16tpm/tpm_tis: Disable interrupts for more Lenovo devicesJerry Snitselaar
The P360 Tiny suffers from an irq storm issue like the T490s, so add an entry for it to tpm_tis_dmi_table, and force polling. There also previously was a report from the previous attempt to enable interrupts that involved a ThinkPad L490. So an entry is added for it as well. Cc: stable@vger.kernel.org Reported-by: Peter Zijlstra <peterz@infradead.org> # P360 Tiny Closes: https://lore.kernel.org/linux-integrity/20230505130731.GO83892@hirez.programming.kicks-ass.net/ Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2023-05-16tpm: Prevent hwrng from activating during resumeJarkko Sakkinen
Set TPM_CHIP_FLAG_SUSPENDED in tpm_pm_suspend() and reset in tpm_pm_resume(). While the flag is set, tpm_hwrng() gives back zero bytes. This prevents hwrng from racing during resume. Cc: stable@vger.kernel.org Fixes: 6e592a065d51 ("tpm: Move Linux RNG connection to hwrng") Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2023-05-16tpm_tis: Use tpm_chip_{start,stop} decoration inside tpm_tis_resumeJarkko Sakkinen
Before sending a TPM command, CLKRUN protocol must be disabled. This is not done in the case of tpm1_do_selftest() call site inside tpm_tis_resume(). Address this by decorating the calls with tpm_chip_{start,stop}, which should be always used to arm and disarm the TPM chip for transmission. Finally, move the call to the main TPM driver callback as the last step because it should arm the chip by itself, if it needs that type of functionality. Cc: stable@vger.kernel.org Reported-by: Jason A. Donenfeld <Jason@zx2c4.com> Closes: https://lore.kernel.org/linux-integrity/CS68AWILHXS4.3M36M1EKZLUMS@suppilovahvero/ Fixes: a3fbfae82b4c ("tpm: take TPM chip power gating out of tpm_transmit()") Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2023-05-15Merge patch series "can: bxcan: add support for single peripheral configuration"Marc Kleine-Budde
Dario Binacchi <dario.binacchi@amarulasolutions.com> says: The series adds support for managing bxCAN controllers in single peripheral configuration. Unlike stm32f4 SOCs, where bxCAN controllers are only in dual peripheral configuration, stm32f7 SOCs contain three CAN peripherals, CAN1 and CAN2 in dual peripheral configuration and CAN3 in single peripheral configuration: - Dual CAN peripheral configuration: * CAN1: Primary bxCAN for managing the communication between a secondary bxCAN and the 512-byte SRAM memory. * CAN2: Secondary bxCAN with no direct access to the SRAM memory. This means that the two bxCAN cells share the 512-byte SRAM memory and CAN2 can't be used without enabling CAN1. - Single CAN peripheral configuration: * CAN3: Primary bxCAN with dedicated Memory Access Controller unit and 512-byte SRAM memory. The driver has been tested on the stm32f769i-discovery board with a kernel version 5.19.0-rc2 in loopback + silent mode: | ip link set can[0-2] type can bitrate 125000 loopback on listen-only on | ip link set up can[0-2] | candump can[0-2] -L & | cansend can[0-2] 300#AC.AB.AD.AE.75.49.AD.D1 Changes in v2: - s/fiter/filter/ in the commit message - Replace struct bxcan_mb::primary with struct bxcan_mb::cfg. - Move after the patch "can: bxcan: add support for single peripheral configuration". - Add node gcan3. - Rename gcan as gcan1. - Add property "st,can-secondary" to can2 node. - Drop patch "dt-bindings: mfd: stm32f7: add binding definition for CAN3" because it has been accepted. - Add patch "ARM: dts: stm32f429: put can2 in secondary mode". - Add patch "dt-bindings: net: can: add "st,can-secondary" property". v1: https://lore.kernel.org/all/20230423172528.1398158-1-dario.binacchi@amarulasolutions.com Link: https://lore.kernel.org/all/20230427204540.3126234-1-dario.binacchi@amarulasolutions.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15ARM: dts: stm32: add CAN support on stm32f746Dario Binacchi
Add support for bxcan (Basic eXtended CAN controller) to STM32F746. The chip contains three CAN peripherals, CAN1 and CAN2 in dual peripheral configuration and CAN3 in single peripheral configuration: - Dual CAN peripheral configuration: * CAN1: Primary bxCAN for managing the communication between a secondary bxCAN and the 512-byte SRAM memory. * CAN2: Secondary bxCAN with no direct access to the SRAM memory. This means that the two bxCAN cells share the 512-byte SRAM memory and CAN2 can't be used without enabling CAN1. - Single CAN peripheral configuration: * CAN3: Primary bxCAN with dedicated Memory Access Controller unit and 512-byte SRAM memory. ------------------------------------------------------------------------- | features | CAN1 | CAN2 | CAN 3 | ------------------------------------------------------------------------- | SRAM | 512-byte shared between CAN1 & CAN2 | 512-byte | ------------------------------------------------------------------------- | Filters | 26 filters shared between CAN1 & CAN2 | 14 filters | ------------------------------------------------------------------------- Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Link: https://lore.kernel.org/all/20230427204540.3126234-6-dario.binacchi@amarulasolutions.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15can: bxcan: add support for single peripheral configurationDario Binacchi
Add support for bxCAN controller in single peripheral configuration: - primary bxCAN - dedicated Memory Access Controller unit - 512-byte SRAM memory - 14 filter banks Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Link: https://lore.kernel.org/all/20230427204540.3126234-5-dario.binacchi@amarulasolutions.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15ARM: dts: stm32: add pin map for CAN controller on stm32f7Dario Binacchi
Add pin configurations for using CAN controller on stm32f7. Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Link: https://lore.kernel.org/all/20230427204540.3126234-4-dario.binacchi@amarulasolutions.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
generated by cgit (git 2.34.1) at 2025-09-15 00:35:46 +0000