aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-05-17can: kvaser_pciefd: Disable interrupts in probe error pathJimmy Assarsson1-0/+2
Disable interrupts in error path of probe function. Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices") Cc: [email protected] Signed-off-by: Jimmy Assarsson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-05-17can: kvaser_pciefd: Do not send EFLUSH command on TFD interruptJimmy Assarsson1-17/+4
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: [email protected] Signed-off-by: Jimmy Assarsson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-05-17can: kvaser_pciefd: Empty SRB buffer in probeJimmy Assarsson1-0/+15
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: [email protected] Signed-off-by: Jimmy Assarsson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-05-17can: kvaser_pciefd: Call request_irq() before enabling interruptsJimmy Assarsson1-5/+5
Make sure the interrupt handler is registered before enabling interrupts. Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices") Cc: [email protected] Signed-off-by: Jimmy Assarsson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-05-17can: kvaser_pciefd: Clear listen-only bit if not explicitly requestedJimmy Assarsson1-0/+2
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: [email protected] Signed-off-by: Jimmy Assarsson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-05-17can: kvaser_pciefd: Set CAN_STATE_STOPPED in kvaser_pciefd_stop()Jimmy Assarsson1-0/+1
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: [email protected] Signed-off-by: Jimmy Assarsson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-05-17wifi: b43: fix incorrect __packed annotationArnd Bergmann2-2/+2
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 <[email protected]> Reported-by: kernel test robot <[email protected]> Reviewed-by: Simon Horman <[email protected]> Tested-by: Larry Finger <[email protected]> Link: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-05-17wifi: rtw88: sdio: Always use two consecutive bytes for word operationsMartin Blumenstingl1-8/+0
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 <[email protected]> Closes: https://lore.kernel.org/linux-wireless/[email protected]/ Reported-by: Rudi Heitbaum <[email protected]> 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 <[email protected]> Signed-off-by: Martin Blumenstingl <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-05-16Merge tag 'ipsec-2023-05-16' of ↵Jakub Kicinski5-74/+29
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/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-05-16Merge tag 'linux-can-fixes-for-6.4-20230515' of ↵Jakub Kicinski9-19/+173
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/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-05-16devlink: Fix crash with CONFIG_NET_NS=nIdo Schimmel1-1/+1
'__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 <[email protected]> Closes: https://lore.kernel.org/netdev/[email protected]/ Tested-by: Marek Szyprowski <[email protected]> Signed-off-by: Ido Schimmel <[email protected]> Reviewed-by: Jiri Pirko <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-05-16scsi: core: Decrease scsi_device's iorequest_cnt if dispatch failedWenchao Hao1-0/+2
If scsi_dispatch_cmd() failed, the SCSI command was not sent to the target, scsi_queue_rq() would return BLK_STS_RESOURCE and the related request would be requeued. The timeout of this request would not fire, no one would increase iodone_cnt. The above flow would result the iodone_cnt smaller than iorequest_cnt. So decrease the iorequest_cnt if dispatch failed to workaround the issue. Signed-off-by: Wenchao Hao <[email protected]> Reported-by: Ming Lei <[email protected]> Closes: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ming Lei <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2023-05-16scsi: Revert "scsi: core: Do not increase scsi_device's iorequest_cnt if ↵Wenchao Hao1-1/+2
dispatch failed" The "atomic_inc(&cmd->device->iorequest_cnt)" in scsi_queue_rq() would cause kernel panic because cmd->device may be freed after returning from scsi_dispatch_cmd(). This reverts commit cfee29ffb45b1c9798011b19d454637d1b0fe87d. Signed-off-by: Wenchao Hao <[email protected]> Reported-by: Ming Lei <[email protected]> Closes: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ming Lei <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2023-05-16scsi: storvsc: Don't pass unused PFNs to Hyper-V hostMichael Kelley1-4/+4
In a SCSI request, storvsc pre-allocates space for up to MAX_PAGE_BUFFER_COUNT physical frame numbers to be passed to Hyper-V. If the size of the I/O request requires more PFNs, a separate memory area of exactly the correct size is dynamically allocated. But when the pre-allocated area is used, current code always passes MAX_PAGE_BUFFER_COUNT PFNs to Hyper-V, even if fewer are needed. While this doesn't break anything because the additional PFNs are always zero, more bytes than necessary are copied into the VMBus channel ring buffer. This takes CPU cycles and wastes space in the ring buffer. For a typical 4 Kbyte I/O that requires only a single PFN, 248 unnecessary bytes are copied. Fix this by setting the payload_sz based on the actual number of PFNs required, not the size of the pre-allocated space. Reported-by: John Starks <[email protected]> Fixes: 8f43710543ef ("scsi: storvsc: Support PAGE_SIZE larger than 4K") Signed-off-by: Michael Kelley <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2023-05-16scsi: ufs: core: Fix MCQ nr_hw_queuesPo-Wen Kao1-1/+2
Since MAXQ is 0-based value, add one to obtain number of hardware queues. Signed-off-by: Po-Wen Kao <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Bean Huo <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Bart Van Assche <[email protected]> Reviewed-by: Stanley Chu <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2023-05-16scsi: ufs: core: Rename symbol sizeof_utp_transfer_cmd_desc()Po-Wen Kao3-7/+7
Naming the functions after standard operators like sizeof() may cause confusion. Rename it to ufshcd_get_ucd_size(). Signed-off-by: Po-Wen Kao <[email protected]> Link: https://lore.kernel.org/r/[email protected] Suggested-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Stanley Chu <[email protected]> Reviewed-by: Ziqi Chen <[email protected]> Reviewed-by: Bart Van Assche <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2023-05-16scsi: ufs: core: Fix MCQ tag calculationPo-Wen Kao2-2/+2
The transfer command descriptor is allocated in ufshcd_memory_alloc() and referenced by the transfer request descriptor with stride size sizeof_utp_transfer_cmd_desc() instead of sizeof(struct utp_transfer_cmd_desc). Consequently, computing tag by address offset should also refer to the same stride. Signed-off-by: Po-Wen Kao <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Bart Van Assche <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Stanley Chu <[email protected]> Reviewed-by: Ziqi Chen <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2023-05-16Documentation/filesystems: ramfs-rootfs-initramfs: use :Author:Randy Dunlap1-2/+1
Use the :Author: markup instead of making it a chapter heading. This cleans up the table of contents for this file. Fixes: 7f46a240b0a1 ("[PATCH] ramfs, rootfs, and initramfs docs") Signed-off-by: Randy Dunlap <[email protected]> Cc: Rob Landley <[email protected]> Reviewed-by: Christian Brauner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Corbet <[email protected]>
2023-05-16Documentation/filesystems: sharedsubtree: add section headingsRandy Dunlap1-0/+4
Several of the sections are missing underlines. This makes the generated contents have missing entries, so add the underlines. Fixes: 16c01b20ae05 ("doc/filesystems: more mount cleanups") Fixes: 9cfcceea8f7e ("[PATCH] Complete description of shared subtrees.") Signed-off-by: Randy Dunlap <[email protected]> Reviewed-by: Christian Brauner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Corbet <[email protected]>
2023-05-16docs: quickly-build-trimmed-linux: various small fixes and improvementsThorsten Leemhuis1-22/+27
* improve the short description of localmodconfig in the step-by-step guide while fixing its broken first sentence * briefly mention immutable Linux distributions * use '--shallow-exclude=v6.0' throughout the document * instead of "git reset --hard; git checkout ..." use "git checkout --force ..." in the step-by-step guide: this matches the TLDR and is one command less to execute. This led to a few small adjustments to the text and the flow in the surrounding area. * fix two thinkos in the section explaining full git clones Signed-off-by: Thorsten Leemhuis <[email protected]> Link: https://lore.kernel.org/r/6f4684b9a5d11d3adb04e0af3cfc60db8b28eeb2.1684140700.git.linux@leemhuis.info Signed-off-by: Jonathan Corbet <[email protected]>
2023-05-16Documentation: use capitalization for chapters and acronymsRandy Dunlap6-8/+8
Use capital letters in acronyms for CD-ROM, FPGA, and PCMCIA. Use capital letter in the first word of chapter headings for Locking, Timers, and "Brief tutorial on CRC computation". Signed-off-by: Randy Dunlap <[email protected]> Cc: Moritz Fischer <[email protected]> Cc: Wu Hao <[email protected]> Cc: Tom Rix <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Will Deacon <[email protected]> Cc: Waiman Long <[email protected]> Cc: Boqun Feng <[email protected]> Cc: Dominik Brodowski <[email protected]> Cc: Thomas Gleixner <[email protected]> Acked-by: Xu Yilun <[email protected]> Reviewed-by: Phillip Potter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Corbet <[email protected]>
2023-05-16ALSA: hda: Fix Oops by 9.1 surround channel namesTakashi Iwai1-3/+4
get_line_out_pfx() may trigger an Oops by overflowing the static array with more than 8 channels. This was reported for MacBookPro 12,1 with Cirrus codec. As a workaround, extend for the 9.1 channels and also fix the potential Oops by unifying the code paths accessing the same array with the proper size check. Reported-by: Olliver Schinagl <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2023-05-16tools headers UAPI: Sync s390 syscall table file that wires up the ↵Arnaldo Carvalho de Melo1-1/+1
memfd_secret syscall To pick the changes in these csets: 7608f70adcb1ea69 ("s390: wire up memfd_secret system call") That add support for this new syscall in tools such as 'perf trace'. For instance, this is now possible (adapted from the x86_64 test output): # perf trace -v -e memfd_secret event qualifier tracepoint filter: (common_pid != 13375 && common_pid != 3713) && (id == 447) ^C# That is the filter expression attached to the raw_syscalls:sys_{enter,exit} tracepoints. $ grep memfd_secret tools/perf/arch/x86/entry/syscalls/syscall_64.tbl 447 common memfd_secret sys_memfd_secret $ This addresses this perf build warnings: Warning: Kernel ABI header at 'tools/perf/arch/s390/entry/syscalls/syscall.tbl' differs from latest version at 'arch/s390/kernel/syscalls/syscall.tbl' diff -u tools/perf/arch/s390/entry/syscalls/syscall.tbl arch/s390/kernel/syscalls/syscall.tbl Cc: Adrian Hunter <[email protected]> Cc: Heiko Carstens <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Vasily Gorbik <[email protected]> Link: https://lore.kernel.org/lkml/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2023-05-16tools headers UAPI: Sync linux/prctl.h with the kernel sourcesArnaldo Carvalho de Melo1-0/+2
ddc65971bb677aa9 ("prctl: add PR_GET_AUXV to copy auxv to userspace") To pick the changes in: That don't result in any changes in tooling: $ tools/perf/trace/beauty/prctl_option.sh > before $ cp include/uapi/linux/prctl.h tools/include/uapi/linux/prctl.h $ tools/perf/trace/beauty/prctl_option.sh > after $ diff -u before after $ This actually adds a new prctl arg, but it has to be dealt with differently, as it is not in sequence with the other arguments. Just silences this perf tools build warning: Warning: Kernel ABI header at 'tools/include/uapi/linux/prctl.h' differs from latest version at 'include/uapi/linux/prctl.h' diff -u tools/include/uapi/linux/prctl.h include/uapi/linux/prctl.h Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2023-05-16perf metrics: Avoid segv with --topdown for metrics without a groupIan Rogers1-1/+1
Some metrics may not have a metric_group which can result in segvs with "perf stat --topdown". Add a condition for the no metric_group case. Fixes: 1647cd5b8802698f ("perf stat: Implement --topdown using json metrics") Reported-by: Kan Liang <[email protected]> Signed-off-by: Ian Rogers <[email protected]> Tested-by: Kan Liang <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kajol Jain <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2023-05-16Merge tag 'asoc-fix-v6.4-rc2' of ↵Takashi Iwai26-81/+276
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v6.4 More fixes that came in since the merge window, the bulk of which are for the SOF code, I suspect as a result of the wide usage, active development and large code size rather than huge quality problems. There's also a couple of MAINTAINERS updates and some new device quirks.
2023-05-16mac80211_hwsim: fix memory leak in hwsim_new_radio_nlZhengchao Shao1-1/+2
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: [email protected] Signed-off-by: Zhengchao Shao <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2023-05-16wifi: iwlwifi: mvm: Add locking to the rate read flowAriel Malamud1-0/+3
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 <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230514120631.b52c9ed5c379.I15290b78e0d966c1b68278263776ca9de841d5fe@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-05-16wifi: iwlwifi: Don't use valid_links to iterate sta linksMiri Korenblit1-30/+22
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 <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230514120631.f32a8c08730a.Ib02248cd0b7f2bc885f91005c3c110dd027f9dcd@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-05-16wifi: iwlwifi: mvm: don't trust firmware n_channelsJohannes Berg1-0/+10
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 <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230514120631.d7b233139eb4.I51fd319df8e9d41881fc8450e83d78049518a79a@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-05-16wifi: iwlwifi: mvm: fix OEM's name in the tas approved listAlon Giladi1-1/+1
Fix a spelling mistake. Fixes: 2856f623ce48 ("iwlwifi: mvm: Add list of OEMs allowed to use TAS") Signed-off-by: Alon Giladi <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230514120631.4090de6d1878.If9391ef6da78f1b2cc5eb6cb8f6965816bb7a7f5@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-05-16wifi: iwlwifi: fix OEM's name in the ppag approved listAlon Giladi1-1/+1
Fix a spelling mistake. Fixes: e8e10a37c51c ("iwlwifi: acpi: move ppag code from mvm to fw/acpi") Signed-off-by: Alon Giladi <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230514120631.fdd07f36a8bf.I223e5fb16ab5c95d504c3fdaffd0bd70affad1c2@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-05-16wifi: iwlwifi: mvm: fix initialization of a return valueMukesh Sisodiya1-1/+1
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 <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230514120631.98b7e3aacf0b.I2fc274dd7e374ef7fac8e26d71c9cd73323da665@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-05-16wifi: iwlwifi: mvm: fix access to fw_id_to_mac_idGregory Greenman4-2/+22
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 <[email protected]> Link: https://lore.kernel.org/r/20230514120631.ec5f2880e81c.Ifa8c0f451df2835bde800f5c3670cc46238a3bd8@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-05-16wifi: iwlwifi: fw: fix DBGI dumpJohannes Berg1-8/+11
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 <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230514120631.19a302ae4c65.I12272599f7c1930666157b9d5e7f81fe9ec4c421@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-05-16wifi: iwlwifi: mvm: fix number of concurrent link checksJohannes Berg2-9/+12
The concurrent link checks need to correctly differentiate between AP and non-AP, fix that. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230514120631.992b2f981ef6.I7d386c19354e9be39c4822f436dd22c93422b660@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-05-16wifi: iwlwifi: mvm: fix cancel_delayed_work_sync() deadlockJohannes Berg1-1/+1
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 <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230514120631.b1813c823b4d.I9d20cc06d24fa40b6774d3dd95ea5e2bf8dd015b@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-05-16wifi: iwlwifi: mvm: don't double-init spinlockJohannes Berg1-5/+5
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 <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230514120631.221c22cfdf4e.I2e30113ef4bd8cb5bd9e1a69e52a95671914961c@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-05-16wifi: iwlwifi: mvm: always free dup_dataJohannes Berg3-5/+3
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 <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230514120631.173938681d72.Iff4b55fc52943825d6e3e28d78a24b155ea5cd22@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-05-16wifi: mac80211: recalc chanctx mindef before assigningJohannes Berg1-0/+3
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 <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2023-05-16wifi: mac80211: consider reserved chanctx for mindefJohannes Berg3-30/+47
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 <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2023-05-16wifi: mac80211: simplify chanctx allocationJohannes Berg1-1/+1
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 <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2023-05-16wifi: mac80211: Abort running color change when stopping the APMichael Lee1-1/+2
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2023-05-16wifi: mac80211: fix min center freq offset tracingJohannes Berg1-1/+1
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 <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2023-05-16wifi: iwlwifi: mvm: rfi: disable RFI featureGregory Greenman3-5/+15
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 <[email protected]> Link: https://lore.kernel.org/linux-wireless/CAAJw_ZvZdFpw9W2Hisc9c2BAFbYAnQuaFFaFG6N7qPUP2fOL_w@mail.gmail.com/ Signed-off-by: Gregory Greenman <[email protected]> Signed-off-by: Johannes Berg <[email protected]>
2023-05-16wifi: mac80211: Fix puncturing bitmap handling in __ieee80211_csa_finalize()Christophe JAILLET1-2/+2
'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 <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://lore.kernel.org/r/e84a3f80fe536787f7a2c7180507efc36cd14f95.1682358088.git.christophe.jaillet@wanadoo.fr Signed-off-by: Johannes Berg <[email protected]>
2023-05-16wifi: mac80211: fortify the spinlock against deadlock by interruptMirsad Goran Todorovac1-2/+3
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/[email protected]/ Reported-by: Mirsad Goran Todorovac <[email protected]> Cc: Gregory Greenman <[email protected]> Cc: Johannes Berg <[email protected]> Link: https://lore.kernel.org/all/[email protected]/ Cc: David S. Miller <[email protected]> Cc: Eric Dumazet <[email protected]> Cc: Jakub Kicinski <[email protected]> Cc: Paolo Abeni <[email protected]> Cc: Leon Romanovsky <[email protected]> Cc: Alexander Wetzel <[email protected]> Signed-off-by: Mirsad Goran Todorovac <[email protected]> Reviewed-by: Leon Romanovsky <[email protected]> Reviewed-by: tag, or it goes automatically? Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2023-05-16wifi: cfg80211: Drop entries with invalid BSSIDs in RNRIlan Peer1-1/+5
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 <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230424103224.5e65d04d1448.Ic10c8577ae4a85272c407106c9d0a2ecb5372743@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-05-16iavf: send VLAN offloading caps once after VFRAhmed Zaki1-5/+0
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 <[email protected]> Tested-by: Rafal Romanowski <[email protected]> Reviewed-by: Leon Romanovsky <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
2023-05-16ice: Fix ice VF reset during iavf initializationDawid Wesierski4-4/+25
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 <[email protected]> Signed-off-by: Kamil Maziarz <[email protected]> Acked-by: Jacob Keller <[email protected]> Tested-by: Rafal Romanowski <[email protected]> Signed-off-by: Tony Nguyen <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.