summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-06-27powerpc/eeh: Fix missing PE bridge reconfiguration during VFIO EEH recoveryNarayana Murty N
[ Upstream commit 33bc69cf6655cf60829a803a45275f11a74899e5 ] VFIO EEH recovery for PCI passthrough devices fails on PowerNV and pseries platforms due to missing host-side PE bridge reconfiguration. In the current implementation, eeh_pe_configure() only performs RTAS or OPAL-based bridge reconfiguration for native host devices, but skips it entirely for PEs managed through VFIO in guest passthrough scenarios. This leads to incomplete EEH recovery when a PCI error affects a passthrough device assigned to a QEMU/KVM guest. Although VFIO triggers the EEH recovery flow through VFIO_EEH_PE_ENABLE ioctl, the platform-specific bridge reconfiguration step is silently bypassed. As a result, the PE's config space is not fully restored, causing subsequent config space access failures or EEH freeze-on-access errors inside the guest. This patch fixes the issue by ensuring that eeh_pe_configure() always invokes the platform's configure_bridge() callback (e.g., pseries_eeh_phb_configure_bridge) even for VFIO-managed PEs. This ensures that RTAS or OPAL calls to reconfigure the PE bridge are correctly issued on the host side, restoring the PE's configuration space after an EEH event. This fix is essential for reliable EEH recovery in QEMU/KVM guests using VFIO PCI passthrough on PowerNV and pseries systems. Tested with: - QEMU/KVM guest using VFIO passthrough (IBM Power9,(lpar)Power11 host) - Injected EEH errors with pseries EEH errinjct tool on host, recovery verified on qemu guest. - Verified successful config space access and CAP_EXP DevCtl restoration after recovery Fixes: 212d16cdca2d ("powerpc/eeh: EEH support for VFIO PCI device") Signed-off-by: Narayana Murty N <nnmlinux@linux.ibm.com> Reviewed-by: Vaibhav Jain <vaibhav@linux.ibm.com> Reviewed-by: Ganesh Goudar <ganeshgr@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250508062928.146043-1-nnmlinux@linux.ibm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27powerpc/vdso: Fix build of VDSO32 with pcrelChristophe Leroy
[ Upstream commit b93755f408325170edb2156c6a894ed1cae5f4f6 ] Building vdso32 on power10 with pcrel leads to following errors: VDSO32A arch/powerpc/kernel/vdso/gettimeofday-32.o arch/powerpc/kernel/vdso/gettimeofday.S: Assembler messages: arch/powerpc/kernel/vdso/gettimeofday.S:40: Error: syntax error; found `@', expected `,' arch/powerpc/kernel/vdso/gettimeofday.S:71: Info: macro invoked from here arch/powerpc/kernel/vdso/gettimeofday.S:40: Error: junk at end of line: `@notoc' arch/powerpc/kernel/vdso/gettimeofday.S:71: Info: macro invoked from here ... make[2]: *** [arch/powerpc/kernel/vdso/Makefile:85: arch/powerpc/kernel/vdso/gettimeofday-32.o] Error 1 make[1]: *** [arch/powerpc/Makefile:388: vdso_prepare] Error 2 Once the above is fixed, the following happens: VDSO32C arch/powerpc/kernel/vdso/vgettimeofday-32.o cc1: error: '-mpcrel' requires '-mcmodel=medium' make[2]: *** [arch/powerpc/kernel/vdso/Makefile:89: arch/powerpc/kernel/vdso/vgettimeofday-32.o] Error 1 make[1]: *** [arch/powerpc/Makefile:388: vdso_prepare] Error 2 make: *** [Makefile:251: __sub-make] Error 2 Make sure pcrel version of CFUNC() macro is used only for powerpc64 builds and remove -mpcrel for powerpc32 builds. Fixes: 7e3a68be42e1 ("powerpc/64: vmlinux support building with PCREL addresing") Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/1fa3453f07d42a50a70114da9905bf7b73304fca.1747073669.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27platform/x86: dell_rbu: Stop overwriting data bufferStuart Hayes
[ Upstream commit f4b0fa38d5fefe9aed6ed831f3bd3538c168ee19 ] The dell_rbu driver will use memset() to clear the data held by each packet when it is no longer needed (when the driver is unloaded, the packet size is changed, etc). The amount of memory that is cleared (before this patch) is the normal packet size. However, the last packet in the list may be smaller. Fix this to only clear the memory actually used by each packet, to prevent it from writing past the end of data buffer. Because the packet data buffers are allocated with __get_free_pages() (in page-sized increments), this bug could only result in a buffer being overwritten when a packet size larger than one page is used. The only user of the dell_rbu module should be the Dell BIOS update program, which uses a packet size of 4096, so no issues should be seen without the patch, it just blocks the possiblity. Fixes: 6c54c28e69f2 ("[PATCH] dell_rbu: new Dell BIOS update driver") Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com> Link: https://lore.kernel.org/r/20250609184659.7210-5-stuart.w.hayes@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27platform/x86: dell_rbu: Fix list usageStuart Hayes
[ Upstream commit 61ce04601e0d8265ec6d2ffa6df5a7e1bce64854 ] Pass the correct list head to list_for_each_entry*() when looping through the packet list. Without this patch, reading the packet data via sysfs will show the data incorrectly (because it starts at the wrong packet), and clearing the packet list will result in a NULL pointer dereference. Fixes: d19f359fbdc6 ("platform/x86: dell_rbu: don't open code list_for_each_entry*()") Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com> Link: https://lore.kernel.org/r/20250609184659.7210-3-stuart.w.hayes@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27platform/x86/amd: pmf: Prevent amd_pmf_tee_deinit() from running twiceMario Limonciello
[ Upstream commit 93103d56650d7a38ed37ba4041578310f82776ae ] If any of the tee init fails, pass up the errors and clear the tee_ctx pointer. This will prevent cleaning up multiple times. Fixes: ac052d8c08f9d ("platform/x86/amd/pmf: Add PMF TEE interface") Suggested-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/r/20250512211154.2510397-3-superm1@kernel.org Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20250522003457.1516679-3-superm1@kernel.org Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27platform/x86/amd: pmc: Clear metrics table at start of cycleMario Limonciello
[ Upstream commit 4dbd11796f3a8eb95647507befc41995458a4023 ] The area of memory that contains the metrics table may contain garbage when the cycle starts. This normally doesn't matter because the cycle itself will populate it with valid data, however commit 9f5595d5f03fd ("platform/x86/amd: pmc: Require at least 2.5 seconds between HW sleep cycles") started to use it during the check() phase. Depending upon what garbage is in the table it's possible that the system will wait 2.5 seconds for even the first cycle, which will be visible to a user. To prevent this from happening explicitly clear the table when logging is started. Fixes: 9f5595d5f03fd ("platform/x86/amd: pmc: Require at least 2.5 seconds between HW sleep cycles") Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20250603132412.3555302-1-superm1@kernel.org Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27fs/xattr.c: fix simple_xattr_list()Stephen Smalley
[ Upstream commit 800d0b9b6a8b1b354637b4194cc167ad1ce2bdd3 ] commit 8b0ba61df5a1 ("fs/xattr.c: fix simple_xattr_list to always include security.* xattrs") failed to reset err after the call to security_inode_listsecurity(), which returns the length of the returned xattr name. This results in simple_xattr_list() incorrectly returning this length even if a POSIX acl is also set on the inode. Reported-by: Collin Funk <collin.funk1@gmail.com> Closes: https://lore.kernel.org/selinux/8734ceal7q.fsf@gmail.com/ Reported-by: Paul Eggert <eggert@cs.ucla.edu> Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2369561 Fixes: 8b0ba61df5a1 ("fs/xattr.c: fix simple_xattr_list to always include security.* xattrs") Signed-off-by: Stephen Smalley <stephen.smalley.work@gmail.com> Link: https://lore.kernel.org/20250605165116.2063-1-stephen.smalley.work@gmail.com Signed-off-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27Revert "bus: ti-sysc: Probe for l4_wkup and l4_cfg interconnect devices first"Alexander Sverdlin
[ Upstream commit 36305857b1ead8f6ca033a913162ebc09bee0b43 ] This reverts commit 4700a00755fb5a4bb5109128297d6fd2d1272ee6. It breaks target-module@2b300050 ("ti,sysc-omap2") probe on AM62x in a case when minimally-configured system tries to network-boot: [ 6.888776] probe of 2b300050.target-module returned 517 after 258 usecs [ 17.129637] probe of 2b300050.target-module returned 517 after 708 usecs [ 17.137397] platform 2b300050.target-module: deferred probe pending: (reason unknown) [ 26.878471] Waiting up to 100 more seconds for network. There are minimal configurations possible when the deferred device is not being probed any more (because everything else has been successfully probed) and deferral lists are not processed any more. Stable mmc enumeration can be achieved by filling /aliases node properly (4700a00755fb commit's rationale). After revert: [ 9.006816] IP-Config: Complete: [ 9.010058] device=lan0, ... Tested-by: Andreas Kemnade <andreas@kemnade.info> # GTA04, Panda, BT200 Reviewed-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Link: https://lore.kernel.org/r/20250401090643.2776793-1-alexander.sverdlin@siemens.com Signed-off-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27tee: Prevent size calculation wraparound on 32-bit kernelsJann Horn
[ Upstream commit 39bb67edcc582b3b386a9ec983da67fa8a10ec03 ] The current code around TEE_IOCTL_PARAM_SIZE() is a bit wrong on 32-bit kernels: Multiplying a user-provided 32-bit value with the size of a structure can wrap around on such platforms. Fix it by using saturating arithmetic for the size calculation. This has no security consequences because, in all users of TEE_IOCTL_PARAM_SIZE(), the subsequent kcalloc() implicitly checks for wrapping. Signed-off-by: Jann Horn <jannh@google.com> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org> Tested-by: Rouven Czerwinski <rouven.czerwinski@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27ARM: OMAP2+: Fix l4ls clk domain handling in STANDBYSukrut Bellary
[ Upstream commit 47fe74098f3dadba2f9cc1e507d813a4aa93f5f3 ] Don't put the l4ls clk domain to sleep in case of standby. Since CM3 PM FW[1](ti-v4.1.y) doesn't wake-up/enable the l4ls clk domain upon wake-up, CM3 PM FW fails to wake-up the MPU. [1] https://git.ti.com/cgit/processor-firmware/ti-amx3-cm3-pm-firmware/ Signed-off-by: Sukrut Bellary <sbellary@baylibre.com> Tested-by: Judith Mendez <jm@ti.com> Link: https://lore.kernel.org/r/20250318230042.3138542-2-sbellary@baylibre.com Signed-off-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27bus: fsl-mc: increase MC_CMD_COMPLETION_TIMEOUT_MS valueLaurentiu Tudor
[ Upstream commit 23d060136841c58c2f9ee8c08ad945d1879ead4b ] In case the MC firmware runs in debug mode with extensive prints pushed to the console, the current timeout of 500ms is not enough. Increase the timeout value so that we don't have any chance of wrongly assuming that the firmware is not responding when it's just taking more time. Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com> Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Link: https://lore.kernel.org/r/20250408105814.2837951-7-ioana.ciornei@nxp.com Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27watchdog: da9052_wdt: respect TWDMINMarcus Folkesson
[ Upstream commit 325f510fcd9cda5a44bcb662b74ba4e3dabaca10 ] We have to wait at least the minimium time for the watchdog window (TWDMIN) before writings to the wdt register after the watchdog is activated. Otherwise the chip will assert TWD_ERROR and power down to reset mode. Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20250326-da9052-fixes-v3-4-a38a560fef0e@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27fbcon: Make sure modelist not set on unregistered consoleKees Cook
[ Upstream commit cedc1b63394a866bf8663a3e40f4546f1d28c8d8 ] It looks like attempting to write to the "store_modes" sysfs node will run afoul of unregistered consoles: UBSAN: array-index-out-of-bounds in drivers/video/fbdev/core/fbcon.c:122:28 index -1 is out of range for type 'fb_info *[32]' ... fbcon_info_from_console+0x192/0x1a0 drivers/video/fbdev/core/fbcon.c:122 fbcon_new_modelist+0xbf/0x2d0 drivers/video/fbdev/core/fbcon.c:3048 fb_new_modelist+0x328/0x440 drivers/video/fbdev/core/fbmem.c:673 store_modes+0x1c9/0x3e0 drivers/video/fbdev/core/fbsysfs.c:113 dev_attr_store+0x55/0x80 drivers/base/core.c:2439 static struct fb_info *fbcon_registered_fb[FB_MAX]; ... static signed char con2fb_map[MAX_NR_CONSOLES]; ... static struct fb_info *fbcon_info_from_console(int console) ... return fbcon_registered_fb[con2fb_map[console]]; If con2fb_map contains a -1 things go wrong here. Instead, return NULL, as callers of fbcon_info_from_console() are trying to compare against existing "info" pointers, so error handling should kick in correctly. Reported-by: syzbot+a7d4444e7b6e743572f7@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/679d0a8f.050a0220.163cdc.000c.GAE@google.com/ Signed-off-by: Kees Cook <kees@kernel.org> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27net/mlx5: HWS, Harden IP version definer checksVlad Dogaru
[ Upstream commit 6991a975e416154576b0f5f06256aec13e23b0a7 ] Replicate some sanity checks that firmware does, since hardware steering does not go through firmware. When creating a definer, disallow matching on IP addresses without also matching on IP version. The latter can be satisfied by matching either on the version field in the IP header, or on the ethertype field. Also refuse to match IPv4 IHL alongside IPv6. Signed-off-by: Vlad Dogaru <vdogaru@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Mark Bloch <mbloch@nvidia.com> Link: https://patch.msgid.link/20250422092540.182091-3-mbloch@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27wifi: ath12k: Pass correct values of center freq1 and center freq2 for 160 MHzSuraj P Kizhakkethil
[ Upstream commit b1b01e46a3db5ad44d1e4691ba37c1e0832cd5cf ] Currently, for 160 MHz bandwidth, center frequency1 and center frequency2 are not passed correctly to the firmware. Set center frequency1 as the center frequency of the primary 80 MHz channel segment and center frequency2 as the center frequency of the 160 MHz channel and pass the values to the firmware. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Signed-off-by: Suraj P Kizhakkethil <quic_surapk@quicinc.com> Reviewed-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Link: https://patch.msgid.link/20250304095315.3050325-2-quic_surapk@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27wifi: ath12k: fix incorrect CE addressesBalamurugan S
[ Upstream commit 60031d9c3589c7983fd1deb4a4c0bebf0929890e ] In the current ath12k implementation, the CE addresses CE_HOST_IE_ADDRESS and CE_HOST_IE_2_ADDRESS are incorrect. These values were inherited from ath11k, but ath12k does not currently use them. However, the Ath12k AHB support relies on these addresses. Therefore, correct the CE addresses for ath12k. Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.3.1-00130-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00210-QCAHKSWPL_SILICONZ-1 Signed-off-by: Balamurugan S <quic_bselvara@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Signed-off-by: Raj Kumar Bhagat <quic_rajkbhag@quicinc.com> Link: https://patch.msgid.link/20250321-ath12k-ahb-v12-2-bb389ed76ae5@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27wifi: ath12k: fix link valid field initialization in the monitor RxHari Chandrakanthan
[ Upstream commit 2826139f9295821fe2b049318a1cc057ec003131 ] Currently, the link_valid field is not initialized in the monitor Rx path. This can result in random values for the link_valid and link_id leads to undefined behaviour in mac80211. Therefore, initialize the link_valid field in the monitor Rx path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Hari Chandrakanthan <quic_haric@quicinc.com> Tested-by: Nicolas Escande <nico.escande@gmail.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Signed-off-by: Karthikeyan Periyasamy <quic_periyasa@quicinc.com> Link: https://patch.msgid.link/20250324062518.2752822-2-quic_periyasa@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27wifi: ath11k: determine PM policy based on machine modelBaochen Qiang
[ Upstream commit ce8669a27016354dfa8bf3c954255cb9f3583bae ] To handle the Lenovo unexpected wakeup issue [1], previously we revert commit 166a490f59ac ("wifi: ath11k: support hibernation"). So currently WLAN target is put into WoWLAN mode during suspend. This is a temporary solution as it does not work on machines where WLAN power is cut off. The thought here is that we do WoWLAN suspend on Lenovo machines while do non-WoWLAN suspend (which is done in the reverted commit) on other machines. This requires us to identify Lenovo machines from others. For that purpose, read board vendor and product name from DMI interface, match it against all known affected machines. If there is a match, choose WoWLAN suspend mode, else choose non-WoWLAN mode. Save the mode in ab for later reference. [1] https://bugzilla.kernel.org/show_bug.cgi?id=219196 Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Tested-by: Muhammad Usama Anjum <usama.anjum@collabora.com> Tested-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Link: https://patch.msgid.link/20250328-ath11k-bring-hibernation-back-v3-1-23405ae23431@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27octeontx2-pf: Add error log forcn10k_map_unmap_rq_policer()Wentao Liang
[ Upstream commit 9c056ec6dd1654b1420dafbbe2a69718850e6ff2 ] The cn10k_free_matchall_ipolicer() calls the cn10k_map_unmap_rq_policer() for each queue in a for loop without checking for any errors. Check the return value of the cn10k_map_unmap_rq_policer() function during each loop, and report a warning if the function fails. Signed-off-by: Wentao Liang <vulab@iscas.ac.cn> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250408032602.2909-1-vulab@iscas.ac.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27net: ethernet: cortina: Use TOE/TSO on all TCPLinus Walleij
[ Upstream commit 6a07e3af4973402fa199a80036c10060b922c92c ] It is desireable to push the hardware accelerator to also process non-segmented TCP frames: we pass the skb->len to the "TOE/TSO" offloader and it will handle them. Without this quirk the driver becomes unstable and lock up and and crash. I do not know exactly why, but it is probably due to the TOE (TCP offload engine) feature that is coupled with the segmentation feature - it is not possible to turn one part off and not the other, either both TOE and TSO are active, or neither of them. Not having the TOE part active seems detrimental, as if that hardware feature is not really supposed to be turned off. The datasheet says: "Based on packet parsing and TCP connection/NAT table lookup results, the NetEngine puts the packets belonging to the same TCP connection to the same queue for the software to process. The NetEngine puts incoming packets to the buffer or series of buffers for a jumbo packet. With this hardware acceleration, IP/TCP header parsing, checksum validation and connection lookup are offloaded from the software processing." After numerous tests with the hardware locking up after something between minutes and hours depending on load using iperf3 I have concluded this is necessary to stabilize the hardware. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patch.msgid.link/20250408-gemini-ethernet-tso-always-v1-1-e669f932359c@linaro.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27bpf, sockmap: Fix data lost during EAGAIN retriesJiayuan Chen
[ Upstream commit 7683167196bd727ad5f3c3fc6a9ca70f54520a81 ] We call skb_bpf_redirect_clear() to clean _sk_redir before handling skb in backlog, but when sk_psock_handle_skb() return EAGAIN due to sk_rcvbuf limit, the redirect info in _sk_redir is not recovered. Fix skb redir loss during EAGAIN retries by restoring _sk_redir information using skb_bpf_set_redir(). Before this patch: ''' ./bench sockmap -c 2 -p 1 -a --rx-verdict-ingress Setting up benchmark 'sockmap'... create socket fd c1:13 p1:14 c2:15 p2:16 Benchmark 'sockmap' started. Send Speed 1343.172 MB/s, BPF Speed 1343.238 MB/s, Rcv Speed 65.271 MB/s Send Speed 1352.022 MB/s, BPF Speed 1352.088 MB/s, Rcv Speed 0 MB/s Send Speed 1354.105 MB/s, BPF Speed 1354.105 MB/s, Rcv Speed 0 MB/s Send Speed 1355.018 MB/s, BPF Speed 1354.887 MB/s, Rcv Speed 0 MB/s ''' Due to the high send rate, the RX processing path may frequently hit the sk_rcvbuf limit. Once triggered, incorrect _sk_redir will cause the flow to mistakenly enter the "!ingress" path, leading to send failures. (The Rcv speed depends on tcp_rmem). After this patch: ''' ./bench sockmap -c 2 -p 1 -a --rx-verdict-ingress Setting up benchmark 'sockmap'... create socket fd c1:13 p1:14 c2:15 p2:16 Benchmark 'sockmap' started. Send Speed 1347.236 MB/s, BPF Speed 1347.367 MB/s, Rcv Speed 65.402 MB/s Send Speed 1353.320 MB/s, BPF Speed 1353.320 MB/s, Rcv Speed 65.536 MB/s Send Speed 1353.186 MB/s, BPF Speed 1353.121 MB/s, Rcv Speed 65.536 MB/s ''' Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev> Link: https://lore.kernel.org/r/20250407142234.47591-2-jiayuan.chen@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27f2fs: fix to set atomic write status more clearChao Yu
[ Upstream commit db03c20c0850dc8d2bcabfa54b9438f7d666c863 ] 1. After we start atomic write in a database file, before committing all data, we'd better not set inode w/ vfs dirty status to avoid redundant updates, instead, we only set inode w/ atomic dirty status. 2. After we commit all data, before committing metadata, we need to clear atomic dirty status, and set vfs dirty status to allow vfs flush dirty inode. Cc: Daeho Jeong <daehojeong@google.com> Reported-by: Zhiguo Niu <zhiguo.niu@unisoc.com> Signed-off-by: Chao Yu <chao@kernel.org> Reviewed-by: Daeho Jeong <daehojeong@google.com> Reviewed-by: Zhiguo Niu <zhiguo.niu@unisoc.com> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27usbnet: asix AX88772: leave the carrier control to phylinkKrzysztof Hałasa
[ Upstream commit 4145f00227ee80f21ab274e9cd9c09758e9bcf3d ] ASIX AX88772B based USB 10/100 Ethernet adapter doesn't come up ("carrier off"), despite the built-in 100BASE-FX PHY positive link indication. The internal PHY is configured (using EEPROM) in fixed 100 Mbps full duplex mode. The primary problem appears to be using carrier_netif_{on,off}() while, at the same time, delegating carrier management to phylink. Use only the latter and remove "manual control" in the asix driver. I don't have any other AX88772 board here, but the problem doesn't seem specific to a particular board or settings - it's probably timing-dependent. Remove unused asix_adjust_link() as well. Signed-off-by: Krzysztof Hałasa <khalasa@piap.pl> Tested-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://patch.msgid.link/m3plhmdfte.fsf_-_@t19.piap.pl Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27ice: fix check for existing switch ruleMateusz Pacuszka
[ Upstream commit a808691df39b52cd9db861b118e88e18b63e2299 ] In case the rule already exists and another VSI wants to subscribe to it new VSI list is being created and both VSIs are moved to it. Currently, the check for already existing VSI with the same rule is done based on fdw_id.hw_vsi_id, which applies only to LOOKUP_RX flag. Change it to vsi_handle. This is software VSI ID, but it can be applied here, because vsi_map itself is also based on it. Additionally change return status in case the VSI already exists in the VSI map to "Already exists". Such case should be handled by the caller. Signed-off-by: Mateusz Pacuszka <mateuszx.pacuszka@intel.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27RDMA/hns: initialize db in update_srq_db()Chen Linxuan
[ Upstream commit ffe1cee21f8b533ae27c3a31bfa56b8c1b27fa6e ] On x86_64 with gcc version 13.3.0, I compile drivers/infiniband/hw/hns/hns_roce_hw_v2.c with: make defconfig ./scripts/kconfig/merge_config.sh .config <( echo CONFIG_COMPILE_TEST=y echo CONFIG_HNS3=m echo CONFIG_INFINIBAND=m echo CONFIG_INFINIBAND_HNS_HIP08=m ) make KCFLAGS="-fno-inline-small-functions -fno-inline-functions-called-once" \ drivers/infiniband/hw/hns/hns_roce_hw_v2.o Then I get a compile error: CALL scripts/checksyscalls.sh DESCEND objtool INSTALL libsubcmd_headers CC [M] drivers/infiniband/hw/hns/hns_roce_hw_v2.o In file included from drivers/infiniband/hw/hns/hns_roce_hw_v2.c:47: drivers/infiniband/hw/hns/hns_roce_hw_v2.c: In function 'update_srq_db': drivers/infiniband/hw/hns/hns_roce_common.h:74:17: error: 'db' is used uninitialized [-Werror=uninitialized] 74 | *((__le32 *)_ptr + (field_h) / 32) &= \ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/infiniband/hw/hns/hns_roce_common.h:90:17: note: in expansion of macro '_hr_reg_clear' 90 | _hr_reg_clear(ptr, field_type, field_h, field_l); \ | ^~~~~~~~~~~~~ drivers/infiniband/hw/hns/hns_roce_common.h:95:39: note: in expansion of macro '_hr_reg_write' 95 | #define hr_reg_write(ptr, field, val) _hr_reg_write(ptr, field, val) | ^~~~~~~~~~~~~ drivers/infiniband/hw/hns/hns_roce_hw_v2.c:948:9: note: in expansion of macro 'hr_reg_write' 948 | hr_reg_write(&db, DB_TAG, srq->srqn); | ^~~~~~~~~~~~ drivers/infiniband/hw/hns/hns_roce_hw_v2.c:946:31: note: 'db' declared here 946 | struct hns_roce_v2_db db; | ^~ cc1: all warnings being treated as errors Signed-off-by: Chen Linxuan <chenlinxuan@uniontech.com> Co-developed-by: Winston Wen <wentao@uniontech.com> Signed-off-by: Winston Wen <wentao@uniontech.com> Link: https://patch.msgid.link/FF922C77946229B6+20250411105459.90782-5-chenlinxuan@uniontech.com Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27ixgbe: Fix unreachable retry logic in combined and byte I2C write functionsRand Deeb
[ Upstream commit cdcb3804eeda24d588348bbab6766cf14fddbeaa ] The current implementation of `ixgbe_write_i2c_combined_generic_int` and `ixgbe_write_i2c_byte_generic_int` sets `max_retry` to `1`, which makes the condition `retry < max_retry` always evaluate to `false`. This renders the retry mechanism ineffective, as the debug message and retry logic are never executed. This patch increases `max_retry` to `3` in both functions, aligning them with the retry logic in `ixgbe_read_i2c_combined_generic_int`. This ensures that the retry mechanism functions as intended, improving robustness in case of I2C write failures. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Rand Deeb <rand.sec96@gmail.com> Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27i40e: fix MMIO write access to an invalid page in i40e_clear_hwKyungwook Boo
[ Upstream commit 015bac5daca978448f2671478c553ce1f300c21e ] When the device sends a specific input, an integer underflow can occur, leading to MMIO write access to an invalid page. Prevent the integer underflow by changing the type of related variables. Signed-off-by: Kyungwook Boo <bookyungwook@gmail.com> Link: https://lore.kernel.org/lkml/ffc91764-1142-4ba2-91b6-8c773f6f7095@gmail.com/T/ Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27sock: Correct error checking condition for (assign|release)_proto_idx()Zijun Hu
[ Upstream commit faeefc173be40512341b102cf1568aa0b6571acd ] (assign|release)_proto_idx() wrongly check find_first_zero_bit() failure by condition '(prot->inuse_idx == PROTO_INUSE_NR - 1)' obviously. Fix by correcting the condition to '(prot->inuse_idx == PROTO_INUSE_NR)' Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com> Link: https://patch.msgid.link/20250410-fix_net-v2-1-d69e7c5739a4@quicinc.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27scsi: lpfc: Use memcpy() for BIOS versionDaniel Wagner
[ Upstream commit ae82eaf4aeea060bb736c3e20c0568b67c701d7d ] The strlcat() with FORTIFY support is triggering a panic because it thinks the target buffer will overflow although the correct target buffer size is passed in. Anyway, instead of memset() with 0 followed by a strlcat(), just use memcpy() and ensure that the resulting buffer is NULL terminated. BIOSVersion is only used for the lpfc_printf_log() which expects a properly terminated string. Signed-off-by: Daniel Wagner <wagi@kernel.org> Link: https://lore.kernel.org/r/20250409-fix-lpfc-bios-str-v1-1-05dac9e51e13@kernel.org Reviewed-by: Justin Tee <justin.tee@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27wifi: ath12k: fix failed to set mhi state error during reboot with hardware ↵Aditya Kumar Singh
grouping [ Upstream commit dce7aec6b1f74b0a46b901ab8de1f7bd0515f733 ] With hardware grouping, during reboot, whenever a device is removed, it powers down itself and all its partner devices in the same group. Now this is done by all devices and hence there is multiple power down for devices and hence the following error messages can be seen: ath12k_pci 0002:01:00.0: failed to set mhi state POWER_OFF(3) in current mhi state (0x0) ath12k_pci 0002:01:00.0: failed to set mhi state: POWER_OFF(3) ath12k_pci 0002:01:00.0: failed to set mhi state DEINIT(1) in current mhi state (0x0) ath12k_pci 0002:01:00.0: failed to set mhi state: DEINIT(1) ath12k_pci 0003:01:00.0: failed to set mhi state POWER_OFF(3) in current mhi state (0x0) ath12k_pci 0003:01:00.0: failed to set mhi state: POWER_OFF(3) ath12k_pci 0003:01:00.0: failed to set mhi state DEINIT(1) in current mhi state (0x0) ath12k_pci 0003:01:00.0: failed to set mhi state: DEINIT(1) ath12k_pci 0004:01:00.0: failed to set mhi state POWER_OFF(3) in current mhi state (0x0) ath12k_pci 0004:01:00.0: failed to set mhi state: POWER_OFF(3) To prevent this, check if the ATH12K_PCI_FLAG_INIT_DONE flag is already set before powering down. If it is set, it indicates that another partner device has already performed the power down, and this device can skip this step. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250408-fix_reboot_issues_with_hw_grouping-v4-3-95e7bf048595@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27pinctrl: mcp23s08: Reset all pins to input at probeMike Looijmans
[ Upstream commit 3ede3f8b4b4b399b0ca41e44959f80d5cf84fc98 ] At startup, the driver just assumes that all registers have their default values. But after a soft reset, the chip will just be in the state it was, and some pins may have been configured as outputs. Any modification of the output register will cause these pins to be driven low, which leads to unexpected/unwanted effects. To prevent this from happening, set the chip's IO configuration register to a known safe mode (all inputs) before toggling any other bits. Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl> Link: https://lore.kernel.org/20250314151803.28903-1-mike.looijmans@topic.nl Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27isofs: fix Y2038 and Y2156 issues in Rock Ridge TF entryJonas 'Sortie' Termansen
[ Upstream commit 5ea45f54c8d6ca2a95b7bd450ee9eb253310bfd3 ] This change implements the Rock Ridge TF entry LONG_FORM bit, which uses the ISO 9660 17-byte date format (up to year 9999, with 10ms precision) instead of the 7-byte date format (up to year 2155, with 1s precision). Previously the LONG_FORM bit was ignored; and isofs would entirely misinterpret the date as the wrong format, resulting in garbage timestamps on the filesystem. The Y2038 issue in iso_date() is fixed by returning a struct timespec64 instead of an int. parse_rock_ridge_inode_internal() is fixed so it does proper bounds checks of the TF entry timestamps. Signed-off-by: Jonas 'Sortie' Termansen <sortie@maxsi.org> Signed-off-by: Jan Kara <jack@suse.cz> Link: https://patch.msgid.link/20250411145022.2292255-1-sortie@maxsi.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27software node: Correct a OOB check in software_node_get_reference_args()Zijun Hu
[ Upstream commit 31e4e12e0e9609850cefd4b2e1adf782f56337d6 ] software_node_get_reference_args() wants to get @index-th element, so the property value requires at least '(index + 1) * sizeof(*ref)' bytes but that can not be guaranteed by current OOB check, and may cause OOB for malformed property. Fix by using as OOB check '((index + 1) * sizeof(*ref) > prop->length)'. Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> Link: https://lore.kernel.org/r/20250414-fix_swnode-v2-1-9c9e6ae11eab@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27net: ethernet: ti: am65-cpsw: handle -EPROBE_DEFERMichael Walle
[ Upstream commit 09737cb80b8686ffca4ed1805fee745d5c85604d ] of_get_mac_address() might fetch the MAC address from NVMEM and that driver might not have been loaded. In that case, -EPROBE_DEFER is returned. Right now, this will trigger an immediate fallback to am65_cpsw_am654_get_efuse_macid() possibly resulting in a random MAC address although the MAC address is stored in the referenced NVMEM. Fix it by handling the -EPROBE_DEFER return code correctly. This also means that the creation of the MDIO device has to be moved to a later stage as -EPROBE_DEFER must not be returned after child devices are created. Signed-off-by: Michael Walle <mwalle@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250414084336.4017237-3-mwalle@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27wifi: ath12k: using msdu end descriptor to check for rx multicast packetsSarika Sharma
[ Upstream commit cb7433cc5cd4d07175dbc41f5a19966e9fae48be ] Currently, the RX multicast broadcast packet check is performed using bit 15 from the info6 field of the MPDU start descriptor. This check can also be done using bit 9 from the info5 field of the MSDU end descriptor. However, in some scenarios multicast bit is not set when fetched from MPDU start descriptor. Therefore, checking the RX multicast broadcast packet from the MSDU end descriptor is more reliable as it is per MSDU. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Signed-off-by: Sarika Sharma <quic_sarishar@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250411061523.859387-2-quic_sarishar@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27bnxt_en: Remove unused field "ref_count" in struct bnxt_ulpKalesh AP
[ Upstream commit 5bccacb4cc32cb835fe2fe100a210332c494e81d ] The "ref_count" field in struct bnxt_ulp is unused after commit a43c26fa2e6c ("RDMA/bnxt_re: Remove the sriov config callback"). So we can just remove it now. Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com> Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20250417172448.1206107-4-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27vxlan: Do not treat dst cache initialization errors as fatalIdo Schimmel
[ Upstream commit 20c76dadc783759fd3819d289c72be590660cc8b ] FDB entries are allocated in an atomic context as they can be added from the data path when learning is enabled. After converting the FDB hash table to rhashtable, the insertion rate will be much higher (*) which will entail a much higher rate of per-CPU allocations via dst_cache_init(). When adding a large number of entries (e.g., 256k) in a batch, a small percentage (< 0.02%) of these per-CPU allocations will fail [1]. This does not happen with the current code since the insertion rate is low enough to give the per-CPU allocator a chance to asynchronously create new chunks of per-CPU memory. Given that: a. Only a small percentage of these per-CPU allocations fail. b. The scenario where this happens might not be the most realistic one. c. The driver can work correctly without dst caches. The dst_cache_*() APIs first check that the dst cache was properly initialized. d. The dst caches are not always used (e.g., 'tos inherit'). It seems reasonable to not treat these allocation failures as fatal. Therefore, do not bail when dst_cache_init() fails and suppress warnings by specifying '__GFP_NOWARN'. [1] percpu: allocation failed, size=40 align=8 atomic=1, atomic alloc failed, no space left (*) 97% reduction in average latency of vxlan_fdb_update() when adding 256k entries in a batch. Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20250415121143.345227-14-idosch@nvidia.com Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27net: bridge: mcast: re-implement br_multicast_{enable, disable}_port functionsYong Wang
[ Upstream commit 4b30ae9adb047dd0a7982975ec3933c529537026 ] When a bridge port STP state is changed from BLOCKING/DISABLED to FORWARDING, the port's igmp query timer will NOT re-arm itself if the bridge has been configured as per-VLAN multicast snooping. Solve this by choosing the correct multicast context(s) to enable/disable port multicast based on whether per-VLAN multicast snooping is enabled or not, i.e. using per-{port, VLAN} context in case of per-VLAN multicast snooping by re-implementing br_multicast_enable_port() and br_multicast_disable_port() functions. Before the patch, the IGMP query does not happen in the last step of the following test sequence, i.e. no growth for tx counter: # ip link add name br1 up type bridge vlan_filtering 1 mcast_snooping 1 mcast_vlan_snooping 1 mcast_querier 1 mcast_stats_enabled 1 # bridge vlan global set vid 1 dev br1 mcast_snooping 1 mcast_querier 1 mcast_query_interval 100 mcast_startup_query_count 0 # ip link add name swp1 up master br1 type dummy # bridge link set dev swp1 state 0 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 1 # sleep 1 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 1 # bridge link set dev swp1 state 3 # sleep 2 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 1 After the patch, the IGMP query happens in the last step of the test: # ip link add name br1 up type bridge vlan_filtering 1 mcast_snooping 1 mcast_vlan_snooping 1 mcast_querier 1 mcast_stats_enabled 1 # bridge vlan global set vid 1 dev br1 mcast_snooping 1 mcast_querier 1 mcast_query_interval 100 mcast_startup_query_count 0 # ip link add name swp1 up master br1 type dummy # bridge link set dev swp1 state 0 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 1 # sleep 1 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 1 # bridge link set dev swp1 state 3 # sleep 2 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 3 Signed-off-by: Yong Wang <yongwang@nvidia.com> Reviewed-by: Andy Roulin <aroulin@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27net: bridge: mcast: update multicast contex when vlan state is changedYong Wang
[ Upstream commit 6c131043eaf1be2a6cc2d228f92ceb626fbcc0f3 ] When the vlan STP state is changed, which could be manipulated by "bridge vlan" commands, similar to port STP state, this also impacts multicast behaviors such as igmp query. In the scenario of per-VLAN snooping, there's a need to update the corresponding multicast context to re-arm the port query timer when vlan state becomes "forwarding" etc. Update br_vlan_set_state() function to enable vlan multicast context in such scenario. Before the patch, the IGMP query does not happen in the last step of the following test sequence, i.e. no growth for tx counter: # ip link add name br1 up type bridge vlan_filtering 1 mcast_snooping 1 mcast_vlan_snooping 1 mcast_querier 1 mcast_stats_enabled 1 # bridge vlan global set vid 1 dev br1 mcast_snooping 1 mcast_querier 1 mcast_query_interval 100 mcast_startup_query_count 0 # ip link add name swp1 up master br1 type dummy # sleep 1 # bridge vlan set vid 1 dev swp1 state 4 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 1 # sleep 1 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 1 # bridge vlan set vid 1 dev swp1 state 3 # sleep 2 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 1 After the patch, the IGMP query happens in the last step of the test: # ip link add name br1 up type bridge vlan_filtering 1 mcast_snooping 1 mcast_vlan_snooping 1 mcast_querier 1 mcast_stats_enabled 1 # bridge vlan global set vid 1 dev br1 mcast_snooping 1 mcast_querier 1 mcast_query_interval 100 mcast_startup_query_count 0 # ip link add name swp1 up master br1 type dummy # sleep 1 # bridge vlan set vid 1 dev swp1 state 4 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 1 # sleep 1 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 1 # bridge vlan set vid 1 dev swp1 state 3 # sleep 2 # ip -j -p stats show dev swp1 group xstats_slave subgroup bridge suite mcast | jq '.[]["multicast"]["igmp_queries"]["tx_v2"]' 3 Signed-off-by: Yong Wang <yongwang@nvidia.com> Reviewed-by: Andy Roulin <aroulin@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27wifi: iwlwifi: Add missing MODULE_FIRMWARE for Qu-c0-jf-b0Víctor Gonzalo
[ Upstream commit 2b801487ac3be7bec561ae62d1a6c4d6f5283f8c ] The module metadata for the firmware file iwlwifi-Qu-c0-jf-b0-* is missing. Signed-off-by: Víctor Gonzalo <victor.gonzalo@anddroptable.net> Link: https://patch.msgid.link/20240313180227.2224780-1-victor.gonzalo@anddroptable.net Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27Revert "mac80211: Dynamically set CoDel parameters per station"Toke Høiland-Jørgensen
[ Upstream commit 4876376988081d636a4c4e5f03a5556386b49087 ] This reverts commit 484a54c2e597dbc4ace79c1687022282905afba0. The CoDel parameter change essentially disables CoDel on slow stations, with some questionable assumptions, as Dave pointed out in [0]. Quoting from there: But here are my pithy comments as to why this part of mac80211 is so wrong... static void sta_update_codel_params(struct sta_info *sta, u32 thr) { - if (thr && thr < STA_SLOW_THRESHOLD * sta->local->num_sta) { 1) sta->local->num_sta is the number of associated, rather than active, stations. "Active" stations in the last 50ms or so, might have been a better thing to use, but as most people have far more than that associated, we end up with really lousy codel parameters, all the time. Mistake numero uno! 2) The STA_SLOW_THRESHOLD was completely arbitrary in 2016. - sta->cparams.target = MS2TIME(50); This, by itself, was probably not too bad. 30ms might have been better, at the time, when we were battling powersave etc, but 20ms was enough, really, to cover most scenarios, even where we had low rate 2Ghz multicast to cope with. Even then, codel has a hard time finding any sane drop rate at all, with a target this high. - sta->cparams.interval = MS2TIME(300); But this was horrible, a total mistake, that is leading to codel being completely ineffective in almost any scenario on clients or APS. 100ms, even 80ms, here, would be vastly better than this insanity. I'm seeing 5+seconds of delay accumulated in a bunch of otherwise happily fq-ing APs.... 100ms of observed jitter during a flow is enough. Certainly (in 2016) there were interactions with powersave that I did not understand, and still don't, but if you are transmitting in the first place, powersave shouldn't be a problemmmm..... - sta->cparams.ecn = false; At the time we were pretty nervous about ecn, I'm kind of sanguine about it now, and reliably indicating ecn seems better than turning it off for any reason. [...] In production, on p2p wireless, I've had 8ms and 80ms for target and interval for years now, and it works great. I think Dave's arguments above are basically sound on the face of it, and various experimentation with tighter CoDel parameters in the OpenWrt community have show promising results[1]. So I don't think there's any reason to keep this parameter fiddling; hence this revert. [0] https://lore.kernel.org/linux-wireless/CAA93jw6NJ2cmLmMauz0xAgC2MGbBq6n0ZiZzAdkK0u4b+O2yXg@mail.gmail.com/ [1] https://forum.openwrt.org/t/reducing-multiplexing-latencies-still-further-in-wifi/133605/130 Suggested-By: Dave Taht <dave.taht@gmail.com> In-memory-of: Dave Taht <dave.taht@gmail.com> Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk> Link: https://patch.msgid.link/20250403183930.197716-1-toke@toke.dk Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27wifi: mac80211: VLAN traffic in multicast pathMuna Sinada
[ Upstream commit 1a4a6a22552ca9d723f28a1fe35eab1b9b3d8b33 ] Currently for MLO, sending out multicast frames on each link is handled by mac80211 only when IEEE80211_HW_MLO_MCAST_MULTI_LINK_TX flag is not set. Dynamic VLAN multicast traffic utilizes software encryption. Due to this, mac80211 should handle transmitting multicast frames on all links for multicast VLAN traffic. Signed-off-by: Muna Sinada <muna.sinada@oss.qualcomm.com> Link: https://patch.msgid.link/20250325213125.1509362-4-muna.sinada@oss.qualcomm.com [remove unnecessary parentheses] Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27bpf: Use proper type to calculate bpf_raw_tp_null_args.mask indexShung-Hsi Yu
[ Upstream commit 53ebef53a657d7957d35dc2b953db64f1bb28065 ] The calculation of the index used to access the mask field in 'struct bpf_raw_tp_null_args' is done with 'int' type, which could overflow when the tracepoint being attached has more than 8 arguments. While none of the tracepoints mentioned in raw_tp_null_args[] currently have more than 8 arguments, there do exist tracepoints that had more than 8 arguments (e.g. iocost_iocg_forgive_debt), so use the correct type for calculation and avoid Smatch static checker warning. Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Shung-Hsi Yu <shung-hsi.yu@suse.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Link: https://lore.kernel.org/bpf/20250418074946.35569-1-shung-hsi.yu@suse.com Closes: https://lore.kernel.org/r/843a3b94-d53d-42db-93d4-be10a4090146@stanley.mountain/ Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27net/mlx5: HWS, Fix IP version decisionVlad Dogaru
[ Upstream commit 5f2f8d8b6800e4fc760c2eccec9b2bd2cacf80cf ] Unify the check for IP version when creating a definer. A given matcher is deemed to match on IPv6 if any of the higher order (>31) bits of source or destination address mask are set. A single packet cannot mix IP versions between source and destination addresses, so it makes no sense that they would be decided on independently. Signed-off-by: Vlad Dogaru <vdogaru@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Mark Bloch <mbloch@nvidia.com> Link: https://patch.msgid.link/20250422092540.182091-2-mbloch@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27netdevsim: Mark NAPI ID on skb in nsim_rcvJoe Damato
[ Upstream commit f71c549b26a33fd62f1e9c7deeba738bfc73fbfc ] Previously, nsim_rcv was not marking the NAPI ID on the skb, leading to applications seeing a napi ID of 0 when using SO_INCOMING_NAPI_ID. To add to the userland confusion, netlink appears to correctly report the NAPI IDs for netdevsim queues but the resulting file descriptor from a call to accept() was reporting a NAPI ID of 0. Signed-off-by: Joe Damato <jdamato@fastly.com> Link: https://patch.msgid.link/20250424002746.16891-2-jdamato@fastly.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27wifi: mac80211_hwsim: Prevent tsf from setting if beacon is disabledEdward Adam Davis
[ Upstream commit c575f5374be7a5c4be4acb9fe6be3a4669d94674 ] Setting tsf is meaningless if beacon is disabled, so check that beacon is enabled before setting tsf. Reported-by: syzbot+064815c6cd721082a52a@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=064815c6cd721082a52a Tested-by: syzbot+064815c6cd721082a52a@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis <eadavis@qq.com> Link: https://patch.msgid.link/tencent_3609AC2EFAAED68CA5A7E3C6D212D1C67806@qq.com Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27wifi: rtw89: 8922a: fix TX fail with wrong VCO settingKuan-Chung Chen
[ Upstream commit 20aac091a15dc7229ef1a268253fe36bb6b2be39 ] An incorrect Voltage Controlled Oscillator (VCO) setting may cause Synthesizer (SYN) unlock, which may lead to a failure in the TX authentication request. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250416081241.36138-3-pkshih@realtek.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27wifi: iwlwifi: pcie: make sure to lock rxq->readMiri Korenblit
[ Upstream commit 1cc2c48c4af81bed5ddbe9f2c9d6e20fa163acf9 ] rxq->read is accessed without the rxq->lock in a few places, Make sure to have the lock there. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Tested-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://patch.msgid.link/20250424153620.73725f207aaa.I1a3e4b6c5fd370e029fdacfcdc9ee335788afa98@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27iommu/amd: Ensure GA log notifier callbacks finish running before module unloadSean Christopherson
[ Upstream commit 94c721ea03c7078163f41dbaa101ac721ddac329 ] Synchronize RCU when unregistering KVM's GA log notifier to ensure all in-flight interrupt handlers complete before KVM-the module is unloaded. Signed-off-by: Sean Christopherson <seanjc@google.com> Link: https://lore.kernel.org/r/20250315031048.2374109-1-seanjc@google.com Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27scsi: smartpqi: Add new PCI IDsDavid Strahan
[ Upstream commit 01b8bdddcfab035cf70fd9981cb20593564cd15d ] Add in support for more PCI devices. All PCI ID entries in Hex. Add PCI IDs for Ramaxel controllers: VID / DID / SVID / SDID ---- ---- ---- ---- Ramaxel SmartHBA RX8238-16i 9005 028f 1018 8238 Ramaxel SSSRAID card 9005 028f 1f3f 0610 Add PCI ID for Alibaba controller: VID / DID / SVID / SDID ---- ---- ---- ---- HBA AS1340 9005 028f 1ded 3301 Add PCI IDs for Inspur controller: VID / DID / SVID / SDID ---- ---- ---- ---- RT0800M6E2i 9005 028f 1bd4 00a3 Add PCI IDs for Delta controllers: VID / DID / SVID / SDID ---- ---- ---- ---- ThinkSystem 4450-8i SAS/SATA/NVMe PCIe Gen4 9005 028f 1d49 0222 24Gb HBA ThinkSystem 4450-16i SAS/SATA/NVMe PCIe Gen4 9005 028f 1d49 0223 24Gb HBA ThinkSystem 4450-8e SAS/SATA PCIe Gen4 9005 028f 1d49 0224 24Gb HBA ThinkSystem RAID 4450-16e PCIe Gen4 24Gb 9005 028f 1d49 0225 Adapter HBA ThinkSystem RAID 5450-16i PCIe Gen4 24Gb Adapter 9005 028f 1d49 0521 ThinkSystem RAID 9450-8i 4GB Flash PCIe Gen4 9005 028f 1d49 0624 24Gb Adapter ThinkSystem RAID 9450-16i 4GB Flash PCIe Gen4 9005 028f 1d49 0625 24Gb Adapter ThinkSystem RAID 9450-16i 4GB Flash PCIe Gen4 9005 028f 1d49 0626 24Gb Adapter ThinkSystem RAID 9450-32i 8GB Flash PCIe Gen4 9005 028f 1d49 0627 24Gb Adapter ThinkSystem RAID 9450-16e 4GB Flash PCIe Gen4 9005 028f 1d49 0628 24Gb Adapter Add PCI ID for Cloudnine Controller: VID / DID / SVID / SDID ---- ---- ---- ---- SmartHBA P6600-24i 9005 028f 1f51 100b Add PCI IDs for Hurraydata Controllers: VID / DID / SVID / SDID ---- ---- ---- ---- HRDT TrustHBA H4100-8i 9005 028f 207d 4044 HRDT TrustHBA H4100-8e 9005 028f 207d 4054 HRDT TrustHBA H4100-16i 9005 028f 207d 4084 HRDT TrustHBA H4100-16e 9005 028f 207d 4094 HRDT TrustRAID D3152s-8i 9005 028f 207d 4140 HRDT TrustRAID D3154s-8i 9005 028f 207d 4240 Reviewed-by: Scott Benesh <scott.benesh@microchip.com> Reviewed-by: Scott Teel <scott.teel@microchip.com> Reviewed-by: Mike McGowen <mike.mcgowen@microchip.com> Signed-off-by: David Strahan <david.strahan@microchip.com> Signed-off-by: Don Brace <don.brace@microchip.com> Link: https://lore.kernel.org/r/20250423183229.538572-3-don.brace@microchip.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-30 16:34:51 +0000