summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2026-03-04nfc: nxp-nci: remove interrupt trigger typeCarl Lee1-1/+1
[ Upstream commit 57be33f85e369ce9f69f61eaa34734e0d3bd47a7 ] For NXP NCI devices (e.g. PN7150), the interrupt is level-triggered and active high, not edge-triggered. Using IRQF_TRIGGER_RISING in the driver can cause interrupts to fail to trigger correctly. Remove IRQF_TRIGGER_RISING and rely on the IRQ trigger type configured via Device Tree. Signed-off-by: Carl Lee <carl.lee@amd.com> Link: https://patch.msgid.link/20260205-fc-nxp-nci-remove-interrupt-trigger-type-v2-1-79d2ed4a7e42@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04myri10ge: avoid uninitialized variable useArnd Bergmann1-1/+27
[ Upstream commit fd24173439c033ffb3c2a2628fcbc9cb65e62bdb ] While compile testing on less common architectures, I noticed that gcc-10 on s390 finds a bug that all other configurations seem to miss: drivers/net/ethernet/myricom/myri10ge/myri10ge.c: In function 'myri10ge_set_multicast_list': drivers/net/ethernet/myricom/myri10ge/myri10ge.c:391:25: error: 'cmd.data0' is used uninitialized in this function [-Werror=uninitialized] 391 | buf->data0 = htonl(data->data0); | ^~ drivers/net/ethernet/myricom/myri10ge/myri10ge.c:392:25: error: '*((void *)&cmd+4)' is used uninitialized in this function [-Werror=uninitialized] 392 | buf->data1 = htonl(data->data1); | ^~ drivers/net/ethernet/myricom/myri10ge/myri10ge.c: In function 'myri10ge_allocate_rings': drivers/net/ethernet/myricom/myri10ge/myri10ge.c:392:13: error: 'cmd.data1' is used uninitialized in this function [-Werror=uninitialized] 392 | buf->data1 = htonl(data->data1); drivers/net/ethernet/myricom/myri10ge/myri10ge.c:1939:22: note: 'cmd.data1' was declared here 1939 | struct myri10ge_cmd cmd; | ^~~ drivers/net/ethernet/myricom/myri10ge/myri10ge.c:393:13: error: 'cmd.data2' is used uninitialized in this function [-Werror=uninitialized] 393 | buf->data2 = htonl(data->data2); drivers/net/ethernet/myricom/myri10ge/myri10ge.c:1939:22: note: 'cmd.data2' was declared here 1939 | struct myri10ge_cmd cmd; It would be nice to understand how to make other compilers catch this as well, but for the moment I'll just shut up the warning by fixing the undefined behavior in this driver. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20260205162935.2126442-1-arnd@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04PCI: Mark Nvidia GB10 to avoid bus resetJohnny-CC Chang1-0/+8
[ Upstream commit c81a2ce6b6a844d1a57d2a69833a9d0f00403f00 ] After asserting Secondary Bus Reset to downstream devices via a GB10 Root Port, the link may not retrain correctly, e.g., the link may retrain with a lower lane count or config accesses to downstream devices may fail. Prevent use of Secondary Bus Reset for devices below GB10. Signed-off-by: Johnny-CC Chang <Johnny-CC.Chang@mediatek.com> [bhelgaas: drop pci_ids.h update (only used once), update commit log] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20251113084441.2124737-1-Johnny-CC.Chang@mediatek.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04PCI: Add ACS quirk for Qualcomm Hamoa & GlymurKrishna Chaitanya Chundru1-0/+4
[ Upstream commit 44d2f70b1fd72c339c72983fcffa181beae3e113 ] The Qualcomm Hamoa & Glymur Root Ports don't advertise an ACS capability, but they do provide ACS-like features to disable peer transactions and validate bus numbers in requests. Add an ACS quirk for Hamoa & Glymur. Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260109-acs_quirk-v1-1-82adf95a89ae@oss.qualcomm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04PCI: Enable ACS after configuring IOMMU for OF platformsManivannan Sadhasivam3-9/+10
[ Upstream commit c41e2fb67e26b04d919257875fa954aa5f6e392e ] Platform, ACPI, or IOMMU drivers call pci_request_acs(), which sets 'pci_acs_enable' to request that ACS be enabled for any devices enumerated in the future. OF platforms called pci_enable_acs() for the first device before of_iommu_configure() called pci_request_acs(), so ACS was never enabled for that device (typically a Root Port). Call pci_enable_acs() later, from pci_dma_configure(), after of_dma_configure() has had a chance to call pci_request_acs(). Here's the call path, showing the move of pci_enable_acs() from pci_acs_init() to pci_dma_configure(), where it always happens after pci_request_acs(): pci_device_add pci_init_capabilities pci_acs_init - pci_enable_acs - if (pci_acs_enable) <-- previous test - ... device_add bus_notify(BUS_NOTIFY_ADD_DEVICE) iommu_bus_notifier iommu_probe_device iommu_init_device dev->bus->dma_configure pci_dma_configure # pci_bus_type.dma_configure of_dma_configure of_iommu_configure pci_request_acs pci_acs_enable = 1 <-- set + pci_enable_acs + if (pci_acs_enable) <-- new test + ... bus_probe_device device_initial_probe ... really_probe dev->bus->dma_configure pci_dma_configure # pci_bus_type.dma_configure ... pci_enable_acs Note that we will now call pci_enable_acs() twice for every device, first from the iommu_probe_device() path and again from the really_probe() path. Presumably that's not an issue since we also call dev->bus->dma_configure() twice. For the ACPI platforms, pci_request_acs() is called during ACPI initialization time itself, independent of the IOMMU framework. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org> Link: https://patch.msgid.link/20260102-pci_acs-v3-1-72280b94d288@oss.qualcomm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04PCI: Fix pci_slot_lock () device lockingKeith Busch1-6/+17
[ Upstream commit 1f5e57c622b4dc9b8e7d291d560138d92cfbe5bf ] Like pci_bus_lock(), pci_slot_lock() needs to lock the bridge device to prevent warnings like: pcieport 0000:e2:05.0: unlocked secondary bus reset via: pciehp_reset_slot+0x55/0xa0 Take and release the lock for the bridge providing the slot for the lock/trylock and unlock routines. Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Link: https://patch.msgid.link/20260130165953.751063-3-kbusch@meta.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04PCI: Mark ASM1164 SATA controller to avoid bus resetAlex Williamson1-0/+10
[ Upstream commit beb2f81792a8a619e5122b6b24a374861309c54b ] User forums report issues when assigning ASM1164 SATA controllers to VMs, especially in configurations with multiple controllers. Logs show the device fails to retrain after bus reset. Reports suggest this is an issue across multiple platforms. The device indicates support for PM reset, therefore the device still has a viable function level reset mechanism. The reporting user confirms the device is well behaved in this use case with bus reset disabled. Reported-by: Patrick Bianchi <patrick.w.bianchi@gmail.com> Link: https://forum.proxmox.com/threads/problems-with-pcie-passthrough-with-two-identical-devices.149003/ Signed-off-by: Alex Williamson <alex.williamson@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260109000211.398300-1-alex.williamson@nvidia.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04net/rds: Clear reconnect pending bitHåkon Bugge1-0/+2
[ Upstream commit b89fc7c2523b2b0750d91840f4e52521270d70ed ] When canceling the reconnect worker, care must be taken to reset the reconnect-pending bit. If the reconnect worker has not yet been scheduled before it is canceled, the reconnect-pending bit will stay on forever. Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com> Signed-off-by: Allison Henderson <allison.henderson@oracle.com> Link: https://patch.msgid.link/20260203055723.1085751-6-achender@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04vmw_vsock: bypass false-positive Wnonnull warning with gcc-16Arnd Bergmann1-1/+1
[ Upstream commit e25dbf561e03c0c5e36228e3b8b784392819ce85 ] The gcc-16.0.1 snapshot produces a false-positive warning that turns into a build failure with CONFIG_WERROR: In file included from arch/x86/include/asm/string.h:6, from net/vmw_vsock/vmci_transport.c:10: In function 'vmci_transport_packet_init', inlined from '__vmci_transport_send_control_pkt.constprop' at net/vmw_vsock/vmci_transport.c:198:2: arch/x86/include/asm/string_32.h:150:25: error: argument 2 null where non-null expected because argument 3 is nonzero [-Werror=nonnull] 150 | #define memcpy(t, f, n) __builtin_memcpy(t, f, n) | ^~~~~~~~~~~~~~~~~~~~~~~~~ net/vmw_vsock/vmci_transport.c:164:17: note: in expansion of macro 'memcpy' 164 | memcpy(&pkt->u.wait, wait, sizeof(pkt->u.wait)); | ^~~~~~ arch/x86/include/asm/string_32.h:150:25: note: in a call to built-in function '__builtin_memcpy' net/vmw_vsock/vmci_transport.c:164:17: note: in expansion of macro 'memcpy' 164 | memcpy(&pkt->u.wait, wait, sizeof(pkt->u.wait)); | ^~~~~~ This seems relatively harmless, and it so far the only instance of this warning I have found. The __vmci_transport_send_control_pkt function is called either with wait=NULL or with one of the type values that pass 'wait' into memcpy() here, but not from the same caller. Replacing the memcpy with a struct assignment is otherwise the same but avoids the warning. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Bobby Eshleman <bobbyeshleman@meta.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Bryan Tan <bryan-bt.tan@broadcom.com> Link: https://patch.msgid.link/20260203163406.2636463-1-arnd@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04net: usb: sr9700: remove code to drive nonexistent multicast filterEthan Nelson-Moore3-28/+5
[ Upstream commit 9a9424c756feee9ee6e717405a9d6fa7bacdef08 ] Several registers referenced in this driver's source code do not actually exist (they are not writable and read as zero in my testing). They exist in this driver because it originated as a copy of the dm9601 driver. Notably, these include the multicast filter registers - this causes the driver to not support multicast packets correctly. Remove the multicast filter code and register definitions. Instead, set the chip to receive all multicast filter packets when any multicast addresses are in the list. Reviewed-by: Simon Horman <horms@kernel.org> (from v1) Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Link: https://patch.msgid.link/20260203013924.28582-1-enelsonmoore@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: ath10k: fix lock protection in ath10k_wmi_event_peer_sta_ps_state_chg()Ziyi Guo1-2/+2
[ Upstream commit 820ba7dd6859ef8b1eaf6014897e7aa4756fc65d ] ath10k_wmi_event_peer_sta_ps_state_chg() uses lockdep_assert_held() to assert that ar->data_lock should be held by the caller, but neither ath10k_wmi_10_2_op_rx() nor ath10k_wmi_10_4_op_rx() acquire this lock before calling this function. The field arsta->peer_ps_state is documented as protected by ar->data_lock in core.h, and other accessors (ath10k_peer_ps_state_disable, ath10k_dbg_sta_read_peer_ps_state) properly acquire this lock. Add spin_lock_bh()/spin_unlock_bh() around the peer_ps_state update, and remove the lockdep_assert_held() to be aligned with new locking, following the pattern used by other WMI event handlers in the driver. Signed-off-by: Ziyi Guo <n7l8m4@u.northwestern.edu> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260123175611.767731-1-n7l8m4@u.northwestern.edu [removed excess blank line] Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04octeontx2-af: Workaround SQM/PSE stalls by disabling stickyGeetha sowjanya1-3/+9
[ Upstream commit 70e9a5760abfb6338d63994d4de6b0778ec795d6 ] NIX SQ manager sticky mode is known to cause stalls when multiple SQs share an SMQ and transmit concurrently. Additionally, PSE may deadlock on transitions between sticky and non-sticky transmissions. There is also a credit drop issue observed when certain condition clocks are gated. work around these hardware errata by: - Disabling SQM sticky operation: - Clear TM6 (bit 15) - Clear TM11 (bit 14) - Disabling sticky → non-sticky transition path that can deadlock PSE: - Clear TM5 (bit 23) - Preventing credit drops by keeping the control-flow clock enabled: - Set TM9 (bit 21) These changes are applied via NIX_AF_SQM_DBG_CTL_STATUS. With this configuration the SQM/PSE maintain forward progress under load without credit loss, at the cost of disabling sticky optimizations. Signed-off-by: Geetha sowjanya <gakula@marvell.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260127125147.1642-1-gakula@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04Bluetooth: btusb: Add device ID for Realtek RTL8761BUJacopo Scannella1-0/+1
[ Upstream commit cc6383d4f0cf6127c0552f94cae517a06ccc6b17 ] Add USB device ID 0x2c0a:0x8761 to the btusb driver fo the Realtek RTL8761BU Bluetooth adapter. Reference: https://www.startech.com/en-us/networking-io/av53c1-usb-bluetooth Signed-off-by: Jacopo Scannella <code@charlie.cat> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04Bluetooth: hci_conn: use mod_delayed_work for active mode timeoutStefan Sørensen1-2/+2
[ Upstream commit 49d0901e260739de2fcc90c0c29f9e31e39a2d9b ] hci_conn_enter_active_mode() uses queue_delayed_work() with the intention that the work will run after the given timeout. However, queue_delayed_work() does nothing if the work is already queued, so depending on the link policy we may end up putting the connection into idle mode every hdev->idle_timeout ms. Use mod_delayed_work() instead so the work is queued if not already queued, and the timeout is updated otherwise. Signed-off-by: Stefan Sørensen <ssorensen@roku.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04ipv4: fib: Annotate access to struct fib_alias.fa_state.Kuniyuki Iwashima2-4/+6
[ Upstream commit 6e84fc395e90465f1418f582a9f7d53c87ab010e ] syzbot reported that struct fib_alias.fa_state can be modified locklessly by RCU readers. [0] Let's use READ_ONCE()/WRITE_ONCE() properly. [0]: BUG: KCSAN: data-race in fib_table_lookup / fib_table_lookup write to 0xffff88811b06a7fa of 1 bytes by task 4167 on cpu 0: fib_alias_accessed net/ipv4/fib_lookup.h:32 [inline] fib_table_lookup+0x361/0xd60 net/ipv4/fib_trie.c:1565 fib_lookup include/net/ip_fib.h:390 [inline] ip_route_output_key_hash_rcu+0x378/0x1380 net/ipv4/route.c:2814 ip_route_output_key_hash net/ipv4/route.c:2705 [inline] __ip_route_output_key include/net/route.h:169 [inline] ip_route_output_flow+0x65/0x110 net/ipv4/route.c:2932 udp_sendmsg+0x13c3/0x15d0 net/ipv4/udp.c:1450 inet_sendmsg+0xac/0xd0 net/ipv4/af_inet.c:859 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0x53a/0x600 net/socket.c:2592 ___sys_sendmsg+0x195/0x1e0 net/socket.c:2646 __sys_sendmmsg+0x185/0x320 net/socket.c:2735 __do_sys_sendmmsg net/socket.c:2762 [inline] __se_sys_sendmmsg net/socket.c:2759 [inline] __x64_sys_sendmmsg+0x57/0x70 net/socket.c:2759 x64_sys_call+0x1e28/0x3000 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc0/0x2a0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff88811b06a7fa of 1 bytes by task 4168 on cpu 1: fib_alias_accessed net/ipv4/fib_lookup.h:31 [inline] fib_table_lookup+0x338/0xd60 net/ipv4/fib_trie.c:1565 fib_lookup include/net/ip_fib.h:390 [inline] ip_route_output_key_hash_rcu+0x378/0x1380 net/ipv4/route.c:2814 ip_route_output_key_hash net/ipv4/route.c:2705 [inline] __ip_route_output_key include/net/route.h:169 [inline] ip_route_output_flow+0x65/0x110 net/ipv4/route.c:2932 udp_sendmsg+0x13c3/0x15d0 net/ipv4/udp.c:1450 inet_sendmsg+0xac/0xd0 net/ipv4/af_inet.c:859 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0x53a/0x600 net/socket.c:2592 ___sys_sendmsg+0x195/0x1e0 net/socket.c:2646 __sys_sendmmsg+0x185/0x320 net/socket.c:2735 __do_sys_sendmmsg net/socket.c:2762 [inline] __se_sys_sendmmsg net/socket.c:2759 [inline] __x64_sys_sendmmsg+0x57/0x70 net/socket.c:2759 x64_sys_call+0x1e28/0x3000 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc0/0x2a0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f value changed: 0x00 -> 0x01 Reported by Kernel Concurrency Sanitizer on: CPU: 1 UID: 0 PID: 4168 Comm: syz.4.206 Not tainted syzkaller #0 PREEMPT(voluntary) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Reported-by: syzbot+d24f940f770afda885cf@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/69783ead.050a0220.c9109.0013.GAE@google.com/ Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260127043528.514160-1-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: iwlegacy: add missing mutex protection in il3945_store_measurement()Ziyi Guo1-0/+2
[ Upstream commit 4dd1dda65265ecbc9f43ffc08e333684cf715152 ] il3945_store_measurement() calls il3945_get_measurement() which internally calls il_send_cmd_sync() without holding il->mutex. However, il_send_cmd_sync() has lockdep_assert_held(&il->mutex) indicating that callers must hold this lock. Other sysfs store functions in the same file properly acquire the mutex: - il3945_store_flags() acquires mutex at 3945-mac.c:3110 - il3945_store_filter_flags() acquires mutex at 3945-mac.c:3144 Add mutex_lock()/mutex_unlock() around the il3945_get_measurement() call in the sysfs store function to fix the missing lock protection. Signed-off-by: Ziyi Guo <n7l8m4@u.northwestern.edu> Acked-by: Stanislaw Gruszka <stf_xl@wp.pl> Link: https://patch.msgid.link/20260125193005.1090429-1-n7l8m4@u.northwestern.edu Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: iwlegacy: add missing mutex protection in il4965_store_tx_power()Ziyi Guo1-0/+2
[ Upstream commit e31fa691d0b1c07b6094a6cf0cce894192c462b3 ] il4965_store_tx_power() calls il_set_tx_power() without holding il->mutex. However, il_set_tx_power() has lockdep_assert_held(&il->mutex) indicating that callers must hold this lock. All other callers of il_set_tx_power() properly acquire the mutex: - il_bg_scan_completed() acquires mutex at common.c:1683 - il_mac_config() acquires mutex at common.c:5006 - il3945_commit_rxon() and il4965_commit_rxon() are called via work queues that hold the mutex (like il4965_bg_alive_start) Add mutex_lock()/mutex_unlock() around the il_set_tx_power() call in the sysfs store function to fix the missing lock protection. Signed-off-by: Ziyi Guo <n7l8m4@u.northwestern.edu> Acked-by: Stanislaw Gruszka <stf_xl@wp.pl> Link: https://patch.msgid.link/20260125194039.1196488-1-n7l8m4@u.northwestern.edu Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04net/rds: No shortcut out of RDS_CONN_ERRORGerd Rausch2-5/+2
[ Upstream commit ad22d24be635c6beab6a1fdd3f8b1f3c478d15da ] RDS connections carry a state "rds_conn_path::cp_state" and transitions from one state to another and are conditional upon an expected state: "rds_conn_path_transition." There is one exception to this conditionality, which is "RDS_CONN_ERROR" that can be enforced by "rds_conn_path_drop" regardless of what state the condition is currently in. But as soon as a connection enters state "RDS_CONN_ERROR", the connection handling code expects it to go through the shutdown-path. The RDS/TCP multipath changes added a shortcut out of "RDS_CONN_ERROR" straight back to "RDS_CONN_CONNECTING" via "rds_tcp_accept_one_path" (e.g. after "rds_tcp_state_change"). A subsequent "rds_tcp_reset_callbacks" can then transition the state to "RDS_CONN_RESETTING" with a shutdown-worker queued. That'll trip up "rds_conn_init_shutdown", which was never adjusted to handle "RDS_CONN_RESETTING" and subsequently drops the connection with the dreaded "DR_INV_CONN_STATE", which leaves "RDS_SHUTDOWN_WORK_QUEUED" on forever. So we do two things here: a) Don't shortcut "RDS_CONN_ERROR", but take the longer path through the shutdown code. b) Add "RDS_CONN_RESETTING" to the expected states in "rds_conn_init_shutdown" so that we won't error out and get stuck, if we ever hit weird state transitions like this again." Signed-off-by: Gerd Rausch <gerd.rausch@oracle.com> Signed-off-by: Allison Henderson <allison.henderson@oracle.com> Link: https://patch.msgid.link/20260122055213.83608-2-achender@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04net: usb: r8152: fix transmit queue timeoutMingj Ye1-0/+2
[ Upstream commit 833dcd75d54f0bf5aa0a0781ff57456b421fbb40 ] When the TX queue length reaches the threshold, the netdev watchdog immediately detects a TX queue timeout. This patch updates the trans_start timestamp of the transmit queue on every asynchronous USB URB submission along the transmit path, ensuring that the network watchdog accurately reflects ongoing transmission activity. Signed-off-by: Mingj Ye <insyelu@gmail.com> Reviewed-by: Hayes Wang <hayeswang@realtek.com> Link: https://patch.msgid.link/20260120015949.84996-1-insyelu@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04openrisc: define arch-specific version of nop()Brian Masney1-0/+2
[ Upstream commit 0dfffa5479d6260d04d021f69203b1926f73d889 ] When compiling a driver written for MIPS on OpenRISC that uses the nop() function, it fails due to the following error: drivers/watchdog/pic32-wdt.c: Assembler messages: drivers/watchdog/pic32-wdt.c:125: Error: unrecognized instruction `nop' The driver currently uses the generic version of nop() from include/asm-generic/barrier.h: #ifndef nop #define nop() asm volatile ("nop") #endif Let's fix this on OpenRISC by defining an architecture-specific version of nop(). This was tested by performing an allmodconfig openrisc cross compile on an aarch64 host. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202601180236.BVy480We-lkp@intel.com/ Signed-off-by: Brian Masney <bmasney@redhat.com> Signed-off-by: Stafford Horne <shorne@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04netfilter: xt_tcpmss: check remaining length before reading optlenFlorian Westphal1-1/+1
[ Upstream commit 735ee8582da3d239eb0c7a53adca61b79fb228b3 ] Quoting reporter: In net/netfilter/xt_tcpmss.c (lines 53-68), the TCP option parser reads op[i+1] directly without validating the remaining option length. If the last byte of the option field is not EOL/NOP (0/1), the code attempts to index op[i+1]. In the case where i + 1 == optlen, this causes an out-of-bounds read, accessing memory past the optlen boundary (either reading beyond the stack buffer _opt or the following payload). Reported-by: sungzii <sungzii@pm.me> Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04netfilter: nf_conntrack: Add allow_clash to generic protocol handlerYuto Hamaguchi1-0/+1
[ Upstream commit 8a49fc8d8a3e83dc51ec05bcd4007bdea3c56eec ] The upstream commit, 71d8c47fc653711c41bc3282e5b0e605b3727956 ("netfilter: conntrack: introduce clash resolution on insertion race"), sets allow_clash=true in the UDP/UDPLITE protocol handler but does not set it in the generic protocol handler. As a result, packets composed of connectionless protocols at each layer, such as UDP over IP-in-IP, still drop packets due to conflicts during conntrack insertion. To resolve this, this patch sets allow_clash in the nf_conntrack_l4proto_generic. Signed-off-by: Yuto Hamaguchi <Hamaguchi.Yuto@da.MitsubishiElectric.co.jp> Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04wifi: libertas: fix WARNING in usb_tx_blockSzymon Wilczek1-0/+2
[ Upstream commit d66676e6ca96bf8680f869a9bd6573b26c634622 ] The function usb_tx_block() submits cardp->tx_urb without ensuring that any previous transmission on this URB has completed. If a second call occurs while the URB is still active (e.g. during rapid firmware loading), usb_submit_urb() detects the active state and triggers a warning: 'URB submitted while active'. Fix this by enforcing serialization: call usb_kill_urb() before submitting the new request. This ensures the URB is idle and safe to reuse. Reported-by: syzbot+67969ab6a2551c27f71b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=67969ab6a2551c27f71b Signed-off-by: Szymon Wilczek <swilczek.lx@gmail.com> Link: https://patch.msgid.link/20251221155806.23925-1-swilczek.lx@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04iommu/arm-smmu-v3: Improve CMDQ lock fairness and efficiencyAlexander Grest1-10/+21
[ Upstream commit df180b1a4cc51011c5f8c52c7ec02ad2e42962de ] The SMMU CMDQ lock is highly contentious when there are multiple CPUs issuing commands and the queue is nearly full. The lock has the following states: - 0: Unlocked - >0: Shared lock held with count - INT_MIN+N: Exclusive lock held, where N is the # of shared waiters - INT_MIN: Exclusive lock held, no shared waiters When multiple CPUs are polling for space in the queue, they attempt to grab the exclusive lock to update the cons pointer from the hardware. If they fail to get the lock, they will spin until either the cons pointer is updated by another CPU. The current code allows the possibility of shared lock starvation if there is a constant stream of CPUs trying to grab the exclusive lock. This leads to severe latency issues and soft lockups. Consider the following scenario where CPU1's attempt to acquire the shared lock is starved by CPU2 and CPU0 contending for the exclusive lock. CPU0 (exclusive) | CPU1 (shared) | CPU2 (exclusive) | `cmdq->lock` -------------------------------------------------------------------------- trylock() //takes | | | 0 | shared_lock() | | INT_MIN | fetch_inc() | | INT_MIN | no return | | INT_MIN + 1 | spins // VAL >= 0 | | INT_MIN + 1 unlock() | spins... | | INT_MIN + 1 set_release(0) | spins... | | 0 see[NOTE] (done) | (sees 0) | trylock() // takes | 0 | *exits loop* | cmpxchg(0, INT_MIN) | 0 | | *cuts in* | INT_MIN | cmpxchg(0, 1) | | INT_MIN | fails // != 0 | | INT_MIN | spins // VAL >= 0 | | INT_MIN | *starved* | | INT_MIN [NOTE] The current code resets the exclusive lock to 0 regardless of the state of the lock. This causes two problems: 1. It opens the possibility of back-to-back exclusive locks and the downstream effect of starving shared lock. 2. The count of shared lock waiters are lost. To mitigate this, we release the exclusive lock by only clearing the sign bit while retaining the shared lock waiter count as a way to avoid starving the shared lock waiters. Also deleted cmpxchg loop while trying to acquire the shared lock as it is not needed. The waiters can see the positive lock count and proceed immediately after the exclusive lock is released. Exclusive lock is not starved in that submitters will try exclusive lock first when new spaces become available. Reviewed-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Alexander Grest <Alexander.Grest@microsoft.com> Signed-off-by: Jacob Pan <jacob.pan@linux.microsoft.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04dm: remove fake timeout to avoid leak requestDing Hui1-2/+1
[ Upstream commit f3a9c95a15d2f4466acad5c68faeff79ca5e9f47 ] Since commit 15f73f5b3e59 ("blk-mq: move failure injection out of blk_mq_complete_request"), drivers are responsible for calling blk_should_fake_timeout() at appropriate code paths and opportunities. However, the dm driver does not implement its own timeout handler and relies on the timeout handling of its slave devices. If an io-timeout-fail error is injected to a dm device, the request will be leaked and never completed, causing tasks to hang indefinitely. Reproduce: 1. prepare dm which has iscsi slave device 2. inject io-timeout-fail to dm echo 1 >/sys/class/block/dm-0/io-timeout-fail echo 100 >/sys/kernel/debug/fail_io_timeout/probability echo 10 >/sys/kernel/debug/fail_io_timeout/times 3. read/write dm 4. iscsiadm -m node -u Result: hang task like below [ 862.243768] INFO: task kworker/u514:2:151 blocked for more than 122 seconds. [ 862.244133] Tainted: G E 6.19.0-rc1+ #51 [ 862.244337] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 862.244718] task:kworker/u514:2 state:D stack:0 pid:151 tgid:151 ppid:2 task_flags:0x4288060 flags:0x00080000 [ 862.245024] Workqueue: iscsi_ctrl_3:1 __iscsi_unbind_session [scsi_transport_iscsi] [ 862.245264] Call Trace: [ 862.245587] <TASK> [ 862.245814] __schedule+0x810/0x15c0 [ 862.246557] schedule+0x69/0x180 [ 862.246760] blk_mq_freeze_queue_wait+0xde/0x120 [ 862.247688] elevator_change+0x16d/0x460 [ 862.247893] elevator_set_none+0x87/0xf0 [ 862.248798] blk_unregister_queue+0x12e/0x2a0 [ 862.248995] __del_gendisk+0x231/0x7e0 [ 862.250143] del_gendisk+0x12f/0x1d0 [ 862.250339] sd_remove+0x85/0x130 [sd_mod] [ 862.250650] device_release_driver_internal+0x36d/0x530 [ 862.250849] bus_remove_device+0x1dd/0x3f0 [ 862.251042] device_del+0x38a/0x930 [ 862.252095] __scsi_remove_device+0x293/0x360 [ 862.252291] scsi_remove_target+0x486/0x760 [ 862.252654] __iscsi_unbind_session+0x18a/0x3e0 [scsi_transport_iscsi] [ 862.252886] process_one_work+0x633/0xe50 [ 862.253101] worker_thread+0x6df/0xf10 [ 862.253647] kthread+0x36d/0x720 [ 862.254533] ret_from_fork+0x2a6/0x470 [ 862.255852] ret_from_fork_asm+0x1a/0x30 [ 862.256037] </TASK> Remove the blk_should_fake_timeout() check from dm, as dm has no native timeout handling and should not attempt to fake timeouts. Signed-off-by: Ding Hui <dinghui@sangfor.com.cn> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04jfs: nlink overflow in jfs_renameJori Koolstra1-2/+4
[ Upstream commit 9218dc26fd922b09858ecd3666ed57dfd8098da8 ] If nlink is maximal for a directory (-1) and inside that directory you perform a rename for some child directory (not moving from the parent), then the nlink of the first directory is first incremented and later decremented. Normally this is fine, but when nlink = -1 this causes a wrap around to 0, and then drop_nlink issues a warning. After applying the patch syzbot no longer issues any warnings. I also ran some basic fs tests to look for any regressions. Signed-off-by: Jori Koolstra <jkoolstra@xs4all.nl> Reported-by: syzbot+9131ddfd7870623b719f@syzkaller.appspotmail.com Closes: https://syzbot.org/bug?extid=9131ddfd7870623b719f Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04jfs: Add missing set_freezable() for freezable kthreadHaotian Zhang1-0/+1
[ Upstream commit eb0cfcf265714b419cc3549895a00632e76732ae ] The jfsIOWait() thread calls try_to_freeze() but lacks set_freezable(), causing it to remain non-freezable by default. This prevents proper freezing during system suspend. Add set_freezable() to make the thread freezable as intended. Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn> Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04modpost: Amend ppc64 save/restfpr symnames for -Os buildRené Rebe1-0/+4
[ Upstream commit 3cd9763ce4ad999d015cf0734e6b968cead95077 ] Building a size optimized ppc64 kernel (-Os), gcc emits more FP save/restore symbols, that the linker generates on demand into the .sfpr section. Explicitly allow-list those in scripts/mod/modpost.c, too. They are needed for the amdgpu in-kernel floating point support. MODPOST Module.symvers ERROR: modpost: "_restfpr_20" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_restfpr_26" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_restfpr_22" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_savegpr1_27" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_savegpr1_25" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_restfpr_28" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_savegpr1_29" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_savefpr_20" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_savefpr_22" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "_restfpr_15" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! WARNING: modpost: suppressed 56 unresolved symbol warnings because there were too many) Signed-off-by: René Rebe <rene@exactco.de> Link: https://patch.msgid.link/20251123.131330.407910684435629198.rene@exactco.de Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04ASoC: es8328: Add error unwind in resumeHsieh Hung-En1-2/+8
[ Upstream commit 8232e6079ae6f8d3a61d87973cb427385aa469b9 ] Handle failures in the resume path by unwinding previously enabled resources. If enabling regulators or syncing the regcache fails, disable regulators and unprepare the clock to avoid leaking resources and leaving the device in a partially resumed state. Signed-off-by: Hsieh Hung-En <hungen3108@gmail.com> Link: https://patch.msgid.link/20260130160017.2630-6-hungen3108@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04spi: spi-mem: Protect dirmap_create() with spi_mem_access_start/endChin-Ting Kuo1-1/+10
[ Upstream commit 53f826ff5e0e3ecb279862ca7cce1491b94bb017 ] spi_mem_dirmap_create() may reconfigure controller-wide settings, which can interfere with concurrent transfers to other devices sharing the same SPI controller but using different chip selects. Wrap the ->dirmap_create() callback with spi_mem_access_start() and spi_mem_access_end() to serialize access and prevent cross-CS interference during dirmap creation. This patch has been verified on a setup where a SPI TPM is connected to CS0 of a SPI controller, while a SPI NOR flash is connected to CS1 of the same controller. Without this patch, spi_mem_dirmap_create() for the SPI NOR flash interferes with ongoing SPI TPM data transfers, resulting in failure to create the TPM device. This was tested on an ASPEED AST2700 EVB. Signed-off-by: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Link: https://patch.msgid.link/20260120123005.1392071-2-chin-ting_kuo@aspeedtech.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04gpio: aspeed-sgpio: Change the macro to support deferred probeBilly Tsai1-2/+3
[ Upstream commit e18533b023ec7a33488bcf33140ce69bbba2894f ] Use module_platform_driver() to replace module_platform_driver_probe(). The former utilizes platform_driver_register(), which allows the driver to defer probing when it doesn't acquire the necessary resources due to probe order. In contrast, the latter uses __platform_driver_probe(), which includes the comment "Note that this is incompatible with deferred probing." Since our SGPIO driver requires access to the clock resource, the former is more suitable. Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com> Link: https://lore.kernel.org/r/20260123-upstream_sgpio-v2-1-69cfd1631400@aspeedtech.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04HID: multitouch: add eGalaxTouch EXC3188 supportThorsten Schmelzer2-0/+4
[ Upstream commit 8e4ac86b2ddd36fe501e20ecfcc080e536df1f48 ] Add support for the for the EXC3188 touchscreen from eGalaxy. Signed-off-by: Thorsten Schmelzer <tschmelzer@topcon.com> Signed-off-by: Michael Tretter <m.tretter@pengutronix.de> Signed-off-by: Jiri Kosina <jkosina@suse.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04drm/atmel-hlcdc: fix use-after-free of drm_crtc_commit after releaseLudovic Desroches1-2/+1
[ Upstream commit bc847787233277a337788568e90a6ee1557595eb ] The atmel_hlcdc_plane_atomic_duplicate_state() callback was copying the atmel_hlcdc_plane state structure without properly duplicating the drm_plane_state. In particular, state->commit remained set to the old state commit, which can lead to a use-after-free in the next drm_atomic_commit() call. Fix this by calling __drm_atomic_helper_duplicate_plane_state(), which correctly clones the base drm_plane_state (including the ->commit pointer). It has been seen when closing and re-opening the device node while another DRM client (e.g. fbdev) is still attached: ============================================================================= BUG kmalloc-64 (Not tainted): Poison overwritten ----------------------------------------------------------------------------- 0xc611b344-0xc611b344 @offset=836. First byte 0x6a instead of 0x6b FIX kmalloc-64: Restoring Poison 0xc611b344-0xc611b344=0x6b Allocated in drm_atomic_helper_setup_commit+0x1e8/0x7bc age=178 cpu=0 pid=29 drm_atomic_helper_setup_commit+0x1e8/0x7bc drm_atomic_helper_commit+0x3c/0x15c drm_atomic_commit+0xc0/0xf4 drm_framebuffer_remove+0x4cc/0x5a8 drm_mode_rmfb_work_fn+0x6c/0x80 process_one_work+0x12c/0x2cc worker_thread+0x2a8/0x400 kthread+0xc0/0xdc ret_from_fork+0x14/0x28 Freed in drm_atomic_helper_commit_hw_done+0x100/0x150 age=8 cpu=0 pid=169 drm_atomic_helper_commit_hw_done+0x100/0x150 drm_atomic_helper_commit_tail+0x64/0x8c commit_tail+0x168/0x18c drm_atomic_helper_commit+0x138/0x15c drm_atomic_commit+0xc0/0xf4 drm_atomic_helper_set_config+0x84/0xb8 drm_mode_setcrtc+0x32c/0x810 drm_ioctl+0x20c/0x488 sys_ioctl+0x14c/0xc20 ret_fast_syscall+0x0/0x54 Slab 0xef8bc360 objects=21 used=16 fp=0xc611b7c0 flags=0x200(workingset|zone=0) Object 0xc611b340 @offset=832 fp=0xc611b7c0 Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com> Reviewed-by: Manikandan Muralidharan <manikandan.m@microchip.com> Link: https://patch.msgid.link/20251024-lcd_fixes_mainlining-v1-2-79b615130dc3@microchip.com Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04drm/atmel-hlcdc: fix memory leak from the atomic_destroy_state callbackLudovic Desroches1-2/+1
[ Upstream commit f12352471061df83a36edf54bbb16284793284e4 ] After several commits, the slab memory increases. Some drm_crtc_commit objects are not freed. The atomic_destroy_state callback only put the framebuffer. Use the __drm_atomic_helper_plane_destroy_state() function to put all the objects that are no longer needed. It has been seen after hours of usage of a graphics application or using kmemleak: unreferenced object 0xc63a6580 (size 64): comm "egt_basic", pid 171, jiffies 4294940784 hex dump (first 32 bytes): 40 50 34 c5 01 00 00 00 ff ff ff ff 8c 65 3a c6 @P4..........e:. 8c 65 3a c6 ff ff ff ff 98 65 3a c6 98 65 3a c6 .e:......e:..e:. backtrace (crc c25aa925): kmemleak_alloc+0x34/0x3c __kmalloc_cache_noprof+0x150/0x1a4 drm_atomic_helper_setup_commit+0x1e8/0x7bc drm_atomic_helper_commit+0x3c/0x15c drm_atomic_commit+0xc0/0xf4 drm_atomic_helper_set_config+0x84/0xb8 drm_mode_setcrtc+0x32c/0x810 drm_ioctl+0x20c/0x488 sys_ioctl+0x14c/0xc20 ret_fast_syscall+0x0/0x54 Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com> Reviewed-by: Manikandan Muralidharan <manikandan.m@microchip.com> Link: https://patch.msgid.link/20251024-lcd_fixes_mainlining-v1-1-79b615130dc3@microchip.com Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04virt: vbox: uapi: Mark inner unions in packed structs as packedThomas Weißschuh1-2/+2
[ Upstream commit c25d01e1c4f2d43f47af87c00e223f5ca7c71792 ] The unpacked unions within a packed struct generates alignment warnings on clang for 32-bit ARM: ./usr/include/linux/vbox_vmmdev_types.h:239:4: error: field u within 'struct vmmdev_hgcm_function_parameter32' is less aligned than 'union (unnamed union at ./usr/include/linux/vbox_vmmdev_types.h:223:2)' and is usually due to 'struct vmmdev_hgcm_function_parameter32' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access] 239 | } u; | ^ ./usr/include/linux/vbox_vmmdev_types.h:254:6: error: field u within 'struct vmmdev_hgcm_function_parameter64::(anonymous union)::(unnamed at ./usr/include/linux/vbox_vmmdev_types.h:249:3)' is less aligned than 'union (unnamed union at ./usr/include/linux/vbox_vmmdev_types.h:251:4)' and is usually due to 'struct vmmdev_hgcm_function_parameter64::(anonymous union)::(unnamed at ./usr/include/linux/vbox_vmmdev_types.h:249:3)' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access] With the recent changes to compile-test the UAPI headers in more cases, these warning in combination with CONFIG_WERROR breaks the build. Fix the warnings. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202512140314.DzDxpIVn-lkp@intel.com/ Reported-by: Nathan Chancellor <nathan@kernel.org> Closes: https://lore.kernel.org/linux-kbuild/20260110-uapi-test-disable-headers-arm-clang-unaligned-access-v1-1-b7b0fa541daa@kernel.org/ Suggested-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/linux-kbuild/29b2e736-d462-45b7-a0a9-85f8d8a3de56@app.fastmail.com/ Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Tested-by: Nicolas Schier <nsc@kernel.org> Reviewed-by: Nicolas Schier <nsc@kernel.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/20260115-kbuild-alignment-vbox-v1-2-076aed1623ff@linutronix.de Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04hyper-v: Mark inner union in hv_kvp_exchg_msg_value as packedThomas Weißschuh1-1/+1
[ Upstream commit 1e5271393d777f6159d896943b4c44c4f3ecff52 ] The unpacked union within a packed struct generates alignment warnings on clang for 32-bit ARM: ./usr/include/linux/hyperv.h:361:2: error: field within 'struct hv_kvp_exchg_msg_value' is less aligned than 'union hv_kvp_exchg_msg_value::(anonymous at ./usr/include/linux/hyperv.h:361:2)' and is usually due to 'struct hv_kvp_exchg_msg_value' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access] 361 | union { | ^ With the recent changes to compile-test the UAPI headers in more cases, this warning in combination with CONFIG_WERROR breaks the build. Fix the warning. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202512140314.DzDxpIVn-lkp@intel.com/ Reported-by: Nathan Chancellor <nathan@kernel.org> Closes: https://lore.kernel.org/linux-kbuild/20260110-uapi-test-disable-headers-arm-clang-unaligned-access-v1-1-b7b0fa541daa@kernel.org/ Suggested-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/linux-kbuild/29b2e736-d462-45b7-a0a9-85f8d8a3de56@app.fastmail.com/ Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Acked-by: Wei Liu (Microsoft) <wei.liu@kernel.org> Tested-by: Nicolas Schier <nsc@kernel.org> Reviewed-by: Nicolas Schier <nsc@kernel.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/20260115-kbuild-alignment-vbox-v1-1-076aed1623ff@linutronix.de Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04drm: Account property blob allocations to memcgXiao Kan1-1/+1
[ Upstream commit 26b4309a3ab82a0697751cde52eb336c29c19035 ] DRM_IOCTL_MODE_CREATEPROPBLOB allows userspace to allocate arbitrary-sized property blobs backed by kernel memory. Currently, the blob data allocation is not accounted to the allocating process's memory cgroup, allowing unprivileged users to trigger unbounded kernel memory consumption and potentially cause system-wide OOM. Mark the property blob data allocation with GFP_KERNEL_ACCOUNT so that the memory is properly charged to the caller's memcg. This ensures existing cgroup memory limits apply and prevents uncontrolled kernel memory growth without introducing additional policy or per-file limits. Signed-off-by: Xiao Kan <814091656@qq.com> Signed-off-by: Xiao Kan <xiao.kan@samsung.com> Link: https://patch.msgid.link/tencent_D12AA2DEDE6F359E1AF59405242FB7A5FD05@qq.com Signed-off-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04media: cx25821: Fix a resource leak in cx25821_dev_setup()Haoxiang Li1-0/+1
[ Upstream commit 68cd8ac994cac38a305200f638b30e13c690753b ] Add release_mem_region() if ioremap() fails to release the memory region obtained by cx25821_get_resources(). Signed-off-by: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04media: solo6x10: Check for out of bounds chip_idKees Cook1-1/+7
[ Upstream commit 0fdf6323c35a134f206dcad5babb4ff488552076 ] Clang with CONFIG_UBSAN_SHIFT=y noticed a condition where a signed type (literal "1" is an "int") could end up being shifted beyond 32 bits, so instrumentation was added (and due to the double is_tw286x() call seen via inlining), Clang decides the second one must now be undefined behavior and elides the rest of the function[1]. This is a known problem with Clang (that is still being worked on), but we can avoid the entire problem by actually checking the existing max chip ID, and now there is no runtime instrumentation added at all since everything is known to be within bounds. Additionally use an unsigned value for the shift to remove the instrumentation even without the explicit bounds checking. Link: https://github.com/ClangBuiltLinux/linux/issues/2144 [1] Suggested-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Kees Cook <kees@kernel.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> [hverkuil: fix checkpatch warning for is_tw286x] Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04media: pvrusb2: fix URB leak in pvr2_send_request_exSzymon Wilczek1-0/+5
[ Upstream commit a8333c8262aed2aedf608c18edd39cf5342680a7 ] When pvr2_send_request_ex() submits a write URB successfully but fails to submit the read URB (e.g. returns -ENOMEM), it returns immediately without waiting for the write URB to complete. Since the driver reuses the same URB structure, a subsequent call to pvr2_send_request_ex() attempts to submit the still-active write URB, triggering a 'URB submitted while active' warning in usb_submit_urb(). Fix this by ensuring the write URB is unlinked and waited upon if the read URB submission fails. Reported-by: syzbot+405dcd13121ff75a9e16@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=405dcd13121ff75a9e16 Signed-off-by: Szymon Wilczek <szymonwilczek@gmx.com> Acked-by: Mike Isely <isely@pobox.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04media: adv7180: fix frame interval in progressive modeThorsten Schmelzer1-0/+7
[ Upstream commit 90289b67c5c1d4c18784059b27460d292e16d208 ] The ADV7280-M may internally convert interlaced video input to progressive video. If this mode is enabled, the ADV7280-M delivers progressive video frames at the field rate of 50 fields per second (PAL) or 60 fields per second (NTSC). Fix the reported frame interval if progressive video is enabled. Signed-off-by: Thorsten Schmelzer <tschmelzer@topcon.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Michael Tretter <m.tretter@pengutronix.de> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04ASoC: wm8962: Don't report a microphone if it's shorted to ground on plugSebastian Krzyszkowiak1-0/+10
[ Upstream commit e590752119029d87ce46d725e11245a52d22e1fe ] This usually means that a TRS plug with no microphone pin has been plugged into a TRRS socket. Cases where a user is plugging in a microphone while pressing a button will be handled via incoming interrupt after the user releases the button, so the microphone will still be detected once it becomes usable. Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260105-wm8962-l5-fixes-v1-3-f4f4eeacf089@puri.sm Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04ASoC: wm8962: Add WM8962_ADC_MONOMIX to "3D Coefficients" maskSebastian Krzyszkowiak1-1/+1
[ Upstream commit 66c26346ae30c883eef70acf9cf9054dfdb4fb2f ] This bit is handled by a separate control. Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260105-wm8962-l5-fixes-v1-1-f4f4eeacf089@puri.sm Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04media: omap3isp: set initial formatHans Verkuil1-0/+8
[ Upstream commit 7575b8dfa91f82fcb34ffd5568ff415ac4685794 ] Initialize the v4l2_format to a default. Empty formats are not allowed in V4L2, so this fixes v4l2-compliance issues: fail: v4l2-test-formats.cpp(514): !pix.width || !pix.height test VIDIOC_G_FMT: FAIL Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04media: omap3isp: isppreview: always clamp in preview_try_format()Hans Verkuil1-13/+8
[ Upstream commit 17e1e1641f74a89824d4de3aa38c78daa5686cc1 ] If prev->input != PREVIEW_INPUT_MEMORY the width and height weren't clamped. Just always clamp. This fixes a v4l2-compliance error: fail: v4l2-test-subdevs.cpp(171): fse.max_width == ~0U || fse.max_height == ~0U fail: v4l2-test-subdevs.cpp(270): ret && ret != ENOTTY test Try VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: FAIL Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04media: omap3isp: isp_video_mbus_to_pix/pix_to_mbus fixesHans Verkuil1-3/+3
[ Upstream commit 44c03802a5191626996ee9db4bac090b164ca340 ] The isp_video_mbus_to_pix/pix_to_mbus functions did not take the last empty entry { 0, } of the formats array into account. As a result, isp_video_mbus_to_pix would accept code 0 and isp_video_pix_to_mbus would select code 0 if no match was found. Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04media: dvb-core: dmxdevfilter must always flush bufsHans Verkuil3-8/+11
[ Upstream commit c4e620eccbef76aa5564ebb295e23d6540e27215 ] Currently the buffers are being filled until full, which works fine for the transport stream, but not when reading sections, those have to be returned to userspace immediately, otherwise dvbv5-scan will just wait forever. Add a 'flush' argument to dvb_vb2_fill_buffer to indicate whether the buffer must be flushed or wait until it is full. Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04parisc: Prevent interrupts during rebootHelge Deller1-0/+3
[ Upstream commit 35ac5a728c878594f2ea6c43b57652a16be3c968 ] Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04arm64: tegra: smaug: Add usb-role-switch supportDiogo Ivo1-0/+2
[ Upstream commit dfa93788dd8b2f9c59adf45ecf592082b1847b7b ] The USB2 port on Smaug is configured for OTG operation but lacked the required 'usb-role-switch' property, leading to a failed probe and a non-functioning USB port. Add the property along with setting the default role to host. Signed-off-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04pstore: ram_core: fix incorrect success return when vmap() failsRuipeng Qi1-0/+7
[ Upstream commit 05363abc7625cf18c96e67f50673cd07f11da5e9 ] In persistent_ram_vmap(), vmap() may return NULL on failure. If offset is non-zero, adding offset_in_page(start) causes the function to return a non-NULL pointer even though the mapping failed. persistent_ram_buffer_map() therefore incorrectly returns success. Subsequent access to prz->buffer may dereference an invalid address and cause crashes. Add proper NULL checking for vmap() failures. Signed-off-by: Ruipeng Qi <ruipengqi3@gmail.com> Link: https://patch.msgid.link/20260203020358.3315299-1-ruipengqi3@gmail.com Signed-off-by: Kees Cook <kees@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2026-05-03 07:15:32 +0300