summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-08-14selftests/bpf: Use ping_command() for IPv6 pings in lwt_ip_encapAndrii Nakryiko
lwt_ip_encap hardcodes the ping6 binary for its IPv6 pings. iputils merged ping6 into ping long ago and distros have started dropping the compat symlink -- Arch's iputils 20250605 ships only arping, clockdiff, ping and tracepath. There, every lwt_ip_encap subtest fails: check_ping_ok:FAIL:ip netns exec ns-lwt-ip-encap-1-0101330 ping6 -c 1 \ -W1 -I veth1 fb04::1 > /dev/null unexpected error: 256 (errno 2) #217/1 lwt_ip_encap_ipv4/egress:FAIL The IPv4 subtests fail too, because check_ping_ok() pings both families. SYS() runs the command through system(), so a missing binary is indistinguishable from an unreachable peer. network_helpers.c has had ping_command() for exactly this since commit 372642ea83ff ("selftests/bpf: Move netcnt test under test_progs"): it falls back to "ping -6" when ping6 is not present. lwt_ip_encap.c is the last hardcoded ping6 user. Fix that. Fixes: f5e288943e2c ("selftests/bpf: Move test_lwt_ip_encap to test_progs") Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Song Liu <song@kernel.org> Link: https://lore.kernel.org/bpf/20260813213558.3103179-1-andrii@kernel.org
2026-08-14spi: Fix DMA mapping ownership on partial map failureMark Brown
Honghui Jiang <jiang_hh2019@163.com> says: A partial DMA mapping failure can leave per-transfer mapping flags set while cur_{tx,rx}_dma_dev are NULL or still refer to the devices used for an earlier message. The subsequent cleanup may then unmap a transfer with a NULL or stale device. Before commit e289df82344f ("spi: Rework per message DMA mapped flag to be per transfer"), partial-failure handling was already incomplete, but __spi_unmap_msg() was gated by cur_msg_mapped, which was set only after the whole message mapped successfully. Earlier mappings could leak, but cleanup could not unmap them with an unpublished device. The per-transfer conversion removed that gate: mapping flags can now remain set while cur_{tx,rx}_dma_dev are still unpublished, turning the leak into a NULL- or stale-device unmap regression. Patch 1 publishes the mapping devices before the loop and unwinds every failure through __spi_unmap_msg(). It keeps the forward declaration so it is independently buildable and straightforward to backport. Patch 2 then removes the declaration by moving __spi_unmap_msg() above __spi_map_msg(). Patch 3 clears the current DMA device pointers once the message has been unmapped, while leaving them intact during partial-map unwind and DMA-to-PIO fallback. Patch 4 adds the DMA mapping KUnit suite as a separate translation unit. Only patch 1 is a stable candidate; patches 2 through 4 are follow-up cleanup and test changes for mainline. Testing: - Patch 1 builds independently with the x86_64 reproducer configuration. - The spi_dma KUnit suite passes all four cases on x86_64 and UML. Moving the DMA device assignments back after the mapping loop makes both failure-path cases fail. - The default and all-tests KUnit configurations both select the suite. - All four reproducer cases complete without an oops when run as the first message, and map/unmap counts are balanced after a successful first message. - After message cleanup, cur_{tx,rx}_dma_dev are NULL. v1: https://lore.kernel.org/r/20260805151456.756579-1-jiang_hh2019@163.com Link: https://patch.msgid.link/20260814031419.43378-1-jiang_hh2019@163.com
2026-08-14spi: Add KUnit coverage for DMA mapping error pathsHonghui Jiang
Add KUnit tests for the __spi_map_msg() error paths. The tests verify that a later TX or RX mapping failure clears the mapping state of earlier transfers and leaves cur_{tx,rx}_dma_dev identifying the current mapping device. A zero-length transfer causes sg_alloc_table() to return -EINVAL, providing deterministic failure injection without test hooks. Additional cases cover successful map/unmap and a message which requires no mapping. Build the DMA suite as a separate translation unit, exposing the two internal mapping helpers only for KUnit through the local internal header. Enable SPI in the default and all-tests KUnit configurations so the suite is exercised there. Signed-off-by: Honghui Jiang <jiang_hh2019@163.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260814031419.43378-5-jiang_hh2019@163.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-14spi: Clear current DMA devices when unmapping a messageHonghui Jiang
The current DMA device pointers remain set after a message has been unmapped. Existing users either check the corresponding mapped flag or access the pointers before finalizing the message, but retaining stale device pointers is fragile. Clear both pointers in spi_unmap_msg() after the internal unmap completes. Keep them intact in __spi_unmap_msg(), since that helper is also used during partial-map unwind and the in-message DMA-to-PIO fallback, before processing of the current message is complete. Suggested-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Honghui Jiang <jiang_hh2019@163.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260814031419.43378-4-jiang_hh2019@163.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-14spi: Move __spi_unmap_msg() before __spi_map_msg()Honghui Jiang
Move __spi_unmap_msg() above __spi_map_msg() so the mapping error path can call it without a forward declaration. This is a code-only relocation with no functional change. Suggested-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Honghui Jiang <jiang_hh2019@163.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260814031419.43378-3-jiang_hh2019@163.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-14spi: Fix DMA mapping ownership on partial map failureHonghui Jiang
If RX mapping fails after TX mapping succeeds, __spi_map_msg() unmaps TX but leaves tx_sg_mapped set. If TX mapping fails on a later transfer, mappings created for earlier transfers remain active. In both cases, cur_{tx,rx}_dma_dev have not yet been updated because they are assigned only after every transfer has been mapped. The subsequent spi_unmap_msg() may therefore unmap the TX mapping again or release earlier mappings using a NULL or stale device. Using a NULL device can trigger an oops. An empty SG table does not prevent the NULL dereference because dma_unmap_sg_attrs() accesses the device before checking the entry count. Publish both mapping devices before mapping starts and unwind all failures through __spi_unmap_msg(). This clears the mapping flags and releases each mapping once with the device that created it. Publishing the devices before the loop also refreshes them when no transfer needs mapping. No mapping flag is set in that case, so current users do not use the pointers as mapping owners. Fixes: e289df82344f ("spi: Rework per message DMA mapped flag to be per transfer") Cc: stable@vger.kernel.org Signed-off-by: Honghui Jiang <jiang_hh2019@163.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260814031419.43378-2-jiang_hh2019@163.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-14ASoC: tas2783-sdw: do not treat read-only Controls as writableAndrey Golovko
The regmap has no writeable_reg callback, so regmap considers every register up to max_register writable. That includes the read-only SDCA Controls the driver itself describes: the Latency of every Entity, the Clock Valid of every Clock Source, the actual power state of the Power Domain Entity, the protection status, the algorithm ready flag and the Extension Unit id and version. Most of them are also listed in tas2783_reg_default[] with a placeholder of zero, even though a default for, say, a latency reading is meaningless. Reading such a Control caches its real value, which no longer matches the placeholder, so regcache_sync() then tries to write it back. The peripheral rejects the transaction with -ENODATA and the sync aborts, leaving the rest of the cache unrestored. Add a writeable_reg callback that refuses the read-only Controls and otherwise keeps the previous behaviour. Every selector it lists is the read-only Control of its Entity type in sdca_function.h, and none of the Controls the driver writes is affected: the requested power state, the mutes, the Cluster Index, the protection mode, the algorithm enable and the file download Controls all stay writable. The list is static because the BIOS on the affected machines describes no Smart Amp SDCA function, so the driver runs its fallback tables and sdca_regmap_writeable() is not available to it. It would be good to have the list confirmed against the hardware documentation, and to know whether the read-only Controls belong in tas2783_reg_default[] at all. Signed-off-by: Andrey Golovko <andrey.golovko@gmail.com> Link: https://patch.msgid.link/20260814094000.22118-2-andrey.golovko@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-14Merge tag 'vfs-7.2-rc8.fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs Pull vfs fixes from Christian Brauner: - Don't warn when a mount is completed from another user namespace. fsopen() records the caller's user namespace in fc->user_ns and hands back an ordinary file descriptor. The task that calls fsconfig(FSCONFIG_CMD_CREATE) doesn't have to be the one that created the context, and mount_capable() lets it through as long as the caller has CAP_SYS_ADMIN over fc->user_ns, which anyone in an ancestor namespace does. So fc->user_ns != current_user_ns() is something an unprivileged user can arrange. Both overlayfs and binfmt_misc WARN_ON() that. Overlayfs already has the same check as a plain error return in ovl_parse_param(). Drop the WARN_ON() and just refuse. Add selftests for both cases. - Reject pid allocations through dead ancestor pid namespaces. Require PIDNS_ADDING in every namespace that will receive the pid before publishing any of them. That preserves the invariant that free_pid() never decrements pid_allocated in a namespace whose child_reaper is no longer live. The existing ENOMEM behavior is unchanged. * tag 'vfs-7.2-rc8.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: pid: reject allocations through dead ancestor pid namespaces selftests/filesystems: test completing a context from another user namespace binfmt_misc: don't warn when the mount is completed from another user namespace ovl: don't warn when the mount is completed from another user namespace
2026-08-14Merge tag 'riscv-for-linus-v7.2-rc8' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Paul Walmsley: - Fix a fault caused when the RISC-V Zbb-enabled strlen() is executed on a string that ends right before a page boundary, when the next page is unmapped - Fix a race with the misaligned vector performance testing code that can prevent the outcome of the test from being stored into the vDSO cache - Fix a kernel warning generated by the ftrace code when ftrace_modify_call_code() runs against a ftrace-traced function where a kprobe has already been attached. This shows up in the bpf kselftests * tag 'riscv-for-linus-v7.2-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: lib: Fix ZBB strnlen reading past count boundary riscv: hwprobe: Register unaligned probes before usermode riscv: ftrace: Fix ftrace_modify_call failure on kprobed functions
2026-08-14erofs: fix EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS on some UP platformsGao Xiang
CONFIG_NR_CPUS doesn't define on some UP platforms (e.g. arm), so this can cause make oldconfig to loop indefinitely when CONFIG_SMP=n: $ make ARCH=arm allmodconfig $ sed -i "/CONFIG_SMP=y/d" .config $ sed -i "/CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS.*/d" .config EROFS LZMA default maximum decompression streams (EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS) [0] (NEW) EROFS LZMA default maximum decompression streams (EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS) [0] (NEW) ... Let's guard NR_CPUS with SMP instead of using a hardcoded arbitrary CPU uplimit here, similar to commit a3344078101c ("mm: make SPLIT_PTE_PTLOCKS depend on SMP"). The initial report from SJ Park was for m68k [1] (m68k is the only arch without NR_CPUS in Kconfig), and that got fixed in commit 1fd495ef09ee ("m68k: Define NR_CPUS to 1") Reported-by: SJ Park <sj@kernel.org> Link: https://lore.kernel.org/all/anuyFHLUGDjZWY4K@XiangdeMacBook-Pro.local/T/#u [1] Closes: https://lore.kernel.org/r/20260728065447.91511-1-sj@kernel.org Reported-by: Guenter Roeck <groeck7@gmail.com> Closes: https://lore.kernel.org/r/87853c96-cc8f-49e6-81b1-02bfe409e372@roeck-us.net Fixes: c9b47e6b2311 ("erofs: cap LZMA stream pool size") Signed-off-by: Gao Xiang <xiang@kernel.org> Tested-by: SJ Park <sj@kernel.org> Tested-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-08-14exfat: keep FITRIM within the requested rangeYang Wen
exfat_find_free_bitmap() searches the entire allocation bitmap and may wrap around to its beginning. exfat_trim_fs() does not verify that the returned cluster is still within the requested FITRIM range. As a result, a partial FITRIM operation may discard free clusters outside the user-specified range and report a trimmed length larger than the requested length. Validate each returned cluster against the requested range and stop the search when it wraps around or passes the range end. Signed-off-by: Yang Wen <anmuxixixi@gmail.com> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
2026-08-14HID: tmff: Use 64-bit arithmetic for force feedback scalingLinmao Li
The logical minimum and maximum values come from the HID report descriptor and cover the full signed 32-bit range. Subtracting them in an int can overflow before the force feedback value is scaled. The subsequent multiplication can overflow as well, producing an incorrect value despite the final range checks. Use 64-bit intermediates for both scaling helpers, as done by commit 48d1677779ad ("HID: pidff: Fix integer overflow in pidff_rescale") for the same arithmetic in the PID driver. This keeps the arithmetic defined for the complete descriptor range before the result is clamped. Fixes: dc76c912145f ("Input: use new FF interface in the HID force feedback drivers") Fixes: b27c9590ca0f ("HID: add support for Thrustmaster FGT Force Feedback wheel") Signed-off-by: Linmao Li <lilinmao@kylinos.cn> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-14HID: multitouch: reclassify HTIX5288 to WIN_8_FORCE_MULTI_INPUT_NSMUXianglin Lin
Commit b5e65ae557da ("HID: multitouch: Add quirk for Hantick 5288 touchpad") assigned MT_CLS_NSMU to the HTIX5288 (0911:5288). This was necessary because the device sometimes fails to send touch release signals when transitioning from >=2 fingers to <2 fingers, and MT_QUIRK_NOT_SEEN_MEANS_UP fixes stuck touches by treating missing contacts as released. However, MT_CLS_NSMU only carries MT_QUIRK_NOT_SEEN_MEANS_UP. It lacks MT_QUIRK_CONTACT_CNT_ACCURATE and MT_QUIRK_IGNORE_DUPLICATES. As a result, after a two-finger scroll finger lift, the device still reports stale coordinates from the released contact in subsequent frames, and the driver overwrites the remaining active slot with those frozen coordinates. The remaining finger appears stuck at the lift position until all fingers are lifted. This was confirmed via evtest on Arch Linux 7.1.3: after TRACKING_ID=-1 for the released slot, every subsequent frame contained duplicate position pairs -- the real moving finger's coordinates followed by the lifted finger's frozen position, both attributed to the active slot. Reclassify the device to MT_CLS_WIN_8_FORCE_MULTI_INPUT_NSMU (0x0018), which preserves the original MT_QUIRK_NOT_SEEN_MEANS_UP fix while adding the necessary Win8 quirks (CONTACT_CNT_ACCURATE, IGNORE_DUPLICATES), preventing stale coordinate contamination. The additional FORCE_MULTI_INPUT flag is harmless here: it separates the mouse and touchpad collections into distinct input devices, which is the standard behavior libinput already expects. Fixes: b5e65ae557da ("HID: multitouch: Add quirk for Hantick 5288 touchpad") Signed-off-by: Xianglin Lin <1021538027@qq.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-14ASoC: SOF: validate topology volume range before allocationPengpeng Hou
SOF treats the topology mixer min and max values as non-negative indices into its volume table. It stores them in signed fields, allocates max + 1 entries through an int argument, and later indexes the table with the stored range. An inverted range is invalid, while a maximum at or above INT_MAX cannot be represented safely after the increment or in the signed fields. Validate the complete range before storing it or allocating the table. Fixes: 311ce4fe7637 ("ASoC: SOF: Add support for loading topologies") Assisted-by: Codex:gpt-5 Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Acked-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://patch.msgid.link/20260814081238.25434-1-pengpeng@iscas.ac.cn Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-14sched/fair: Fix flat hierarchyVincent Guittot
When a fair task is enqueued, we must update curr and more precisely its vruntime before placing the enqueued task so avg vruntime will take into account the last exec phase. Example: TA is an always running task in cgroup G0. TB is a short running task (cyclictest) in cgroup G1. The lag of TB always increases up the clamp limit because TB is placed before TA(curr) is updated (since the last tick). When curr(TA) is finally updated, its last exec phase provide positive lag to TB Because TA and TB don't belong to the same group, enqueue_hierarchy() will not update TA's entity when updating curr but only G0's entity at root level. The same applies when dequeuing. This is because update_curr() uses ->h_curr, rather than ->curr, and therefore, while it is invoked on the root cfs_rq, which contains all the eevdf bits, it does not do the right thing. Fixes: 85570f10a4c6 ("sched/eevdf: Move to a single runqueue") Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260812125039.1717249-1-vincent.guittot@linaro.org
2026-08-14Merge branch 'sched/urgent'Peter Zijlstra
Pull in dependents, the flat hierarchy fix depends on this. Signed-off-by: Peter Zijlstra <peterz@infradead.org>
2026-08-14sched: Update time before requeueing delayed entitiesVincent Guittot
In order to compute the right lag, it is required to update time to 'now'. Without this, the delayed entity might appear younger than it really is and receive less compensation for having waited. Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
2026-08-14eventfs: Add warning for out of bounds pos in __eventfs_iterate()Steven Rostedt
Sashiko has complained about out of bounds issues if ctx->pos isn't what is expected in __eventfs_iterate()[1]. This would be an issue if the logic that calls __eventfs_iterate() didn't already prevent the code from going out of bounds. The issue Sashiko brings up is if a user uses lseek64() to put in a position like 0x100000000 which will overflow the integer used to iterate the files. This should never be an issue because both tracefs and eventfs uses the default "maxbytes" for its superblock "s_maxbytes" field which is defined as: fs/super.c: s->s_maxbytes = MAX_NON_LFS; include/linux/fs.h:#define MAX_NON_LFS ((1UL<<31) - 1) Where MAX_NON_LFS turns into 0x7fffffff. Testing this with code to try to pass 0x100000000 to lseek64() to a eventfs directory returns -EINVAL. But relying on logic for the integrity of a function is not very robust. Add a WARN_ON_ONCE() in case the ctx->pos is out of the expected range. [1] https://sashiko.dev/#/patchset/20260810160708.3460a2fd%40gandalf.local.home Link: https://patch.msgid.link/20260810175928.5f4d9d5c@gandalf.local.home Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-08-14tracing: Have trace_event_update_all() only handle module that is loadingSteven Rostedt
The function trace_event_update_all() does a scan of events looking to replace enums with their values in the strings that get exported to the event format files. It's run at boot up on all events and again when a module loads. The issue is that when a module loads, it still runs on *all* events. There's no reason to process every event when a module loads as the previous events have already been processed. Only execute on the events that are loaded with the module. Link: https://patch.msgid.link/20260813204226.29563591@gandalf.local.home Fixes: 3673b8e4ce723 ("tracing: Allow for modules to convert their enums to values") Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-08-14HID: sensor: custom: Fix field sysfs group cleanup on failureHaoxiang Li
hid_sensor_custom_add_attributes() creates one sysfs group for each custom sensor field. If sysfs_create_group() fails after some groups have already been created, the function returns the error without removing the previously created groups. Add a local unwind path to remove the groups that were already created. With enable_sensor exposed only after the field attributes are ready, this path can free sensor_inst->fields without leaving enable_sensor able to access pointers into that array. Fixes: 4a7de0519df5 ("HID: sensor: Custom and Generic sensor support") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-14HID: sensor: custom: Fix use-after-free in enable_sensorHaoxiang Li
enable_sensor_store() can call set_power_report_state(), which dereferences sensor_inst->power_state and sensor_inst->report_state. These pointers refer to entries in sensor_inst->fields. Create the field attributes before exposing the enable_sensor sysfs attribute, so enable_sensor cannot be accessed before the state it depends on has been initialized. On remove, delete enable_sensor before freeing the field attributes, so a concurrent sysfs write cannot dereference freed memory through power_state or report_state. Reported-by: Sashiko AI Review <sashiko-bot@kernel.org> Link: https://sashiko.dev/#/patchset/20260623021950.1736413-1-haoxiang_li2024@163.com?part=1 Fixes: 4a7de0519df5 ("HID: sensor: Custom and Generic sensor support") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-14HID: intel-thc-hid: intel-quickspi: bound GET_REPORT response to the caller ↵HyeongJun An
buffer quickspi_hid_raw_request() receives the caller's buffer length in len, but quickspi_get_report() never sees it and copies the whole device-supplied response into buf regardless: memcpy(buf, qsdev->report_buf, qsdev->report_len); qsdev->report_len comes from the input report the touch controller returns, while buf is sized to whatever the caller asked hidraw for through HIDIOCGFEATURE or HIDIOCGINPUT. A response larger than that overflows buf with device-controlled content. The intel-quicki2c sibling already passes the caller length down to quicki2c_get_report() and validates the response against it before the copy. Do the same here. Fixes: 4138f21115ae ("HID: intel-thc-hid: intel-quickspi: Complete THC QuickSPI driver") Suggested-by: Sashiko AI <sashiko-bot@kernel.org> Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: HyeongJun An <sammiee5311@gmail.com> Reviewed-by: Even Xu <even.xu@intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-14drm: use drm_warn() in validate_blend_mode_for_alpha_formats()Leandro Ribeiro
Commit 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed") introduced a WARN() to let driver developers know that a previously valid behavior should now be changed. But WARN() should not be used for that, as it's a kernel warning report mechanism for conditions that are not expected to happen. It also produces a stack trace. Instead, a simple warning-level log message should have been used, as drivers were expected to trigger the condition. This is causing problems for fuzzers, as they may stop when encountering a "BUG:" or "WARNING:" in the logs. Replace WARN() with drm_warn() in this function, avoiding these issues. Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed") Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Link: https://patch.msgid.link/20260731154232.37020-2-leandro.ribeiro@collabora.com Signed-off-by: Daniel Stone <daniels@collabora.com>
2026-08-14drm/virtio: use the DMA API for resource backing on XenBenjamin Leggett
On a Xen PV domain page addresses bear no relation to the real machine addresses the host would have to use to reach it. virtio_ring.c handles this correctly, vring_use_map_api() returns true for any xen_domain() regardless of VIRTIO_F_ACCESS_PLATFORM. virtio-gpu makes the same decision independently, but its copy looks only at the feature bit: bool use_dma_api = !virtio_has_dma_quirk(vgdev->vdev); QEMU does not set iommu_platform on virtio-vga by default, so VIRTIO_F_ACCESS_PLATFORM is not negotiated, use_dma_api is false, and virtio_gpu_object_shmem_init() describes the framebuffer's backing pages to the host with sg_phys(). Those are guest-physical addresses. In a PV domain they resolve, on the host side, to pages belonging to some other domain, so the host scans out unrelated memory. Move the decision into virtio_gpu_use_dma_api() and give it the xen_domain() check, like vring_use_map_api() has. This additionally enables the dma_sync_sgtable_for_device() calls in virtgpu_vq.c, which are required for correctness whenever swiotlb is in play. Reproduced with a Xen 4.21 PV dom0 nested inside QEMU 8.2 with virtio-vga, on both a distro 6.8 kernel and 6.18 LTS. A PVH dom0 works fine and doesn't need this fix because it is identity-mapped, only PV dom0s are affected. Fixes: a3b815f09bb8 ("drm/virtio: add iommu support.") Signed-off-by: Ben Leggett <benjamin@edera.io> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patch.msgid.link/20260806-virtgpu-xen-dma-v1-1-e499b345bbad@edera.io
2026-08-14drm/virtio: reclaim pending vbufs before tearing down vqsAnuj Bolewar
virtio_gpu_free_vbufs() destroys the vbufs kmem_cache after the virtqueues have already been released. Commands that were queued but never completed by the device leave their vbuffers stranded in the virtqueue, so the cache still holds live objects when virtio_gpu_deinit() tears everything down. This triggers a WARNING in virtio_gpu_free_vbufs: BUG virtio-gpu-vbufs (Not tainted): Objects remaining in cache on __kmem_cache_shutdown() Drain any buffers still sitting in the control and cursor virtqueues in virtio_gpu_deinit() after the device has been reset and before the virtqueues are deleted, following the same pattern used by virtio_console's remove_vqs(). Each reclaimed buffer is released with free_vbuf(), dropping the reference on any GEM objects it holds. Pending RESOURCE_UNREF commands are handled as well: their resp_cb_data still references a GEM object, so it is cleaned up with virtio_gpu_cleanup_object() to avoid leaking it on teardown. Reported-by: syzbot+06f9b2a53ba4a5a47644@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=06f9b2a53ba4a5a47644 Signed-off-by: Anuj Bolewar <bolewara@gmail.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patch.msgid.link/20260802-virtio-gpu-reclaim-vbufs-v2-1-5767fb860691@gmail.com
2026-08-14drm/virtio: check return value of vgdev_output_init()shechenglong
The return value of vgdev_output_init(), called by virtio_gpu_modeset_init(), is not checked. As a result, modeset initialization continues even if an output fails to initialize. check the return value and return the error to the caller. Signed-off-by: shechenglong <shechenglong@xfusion.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patch.msgid.link/20260811015624.830-1-shechenglong@xfusion.com
2026-08-14HID: haptic: don't write an uninitialized value to unhandled usagesKarl Mehltretter
fill_effect_buf() initializes value only for the four haptic usages handled by its switch, but writes it to field->value[] for every usage. An unhandled usage can therefore receive either an uninitialized value or one left over from the previous usage. hid_output_report() then serializes that value into the effect's report buffer. Skip unhandled usages instead. This also matches switch_mode(), which only updates fields it recognizes. Found with Clang's -Wconditional-uninitialized. Fixes: 344ff3584957 ("HID: haptic: initialize haptic device") Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-14HID: intel-thc-hid: intel-quickspi: fix autosuspend cleanup during teardownGuangshuo Li
quickspi_probe() calls pm_runtime_use_autosuspend(), but quickspi_remove() does not call the matching pm_runtime_dont_use_autosuspend() during teardown. If the autosuspend delay is set to a negative value while autosuspend is enabled, the runtime PM core increments usage_count to prevent runtime suspend. Without calling pm_runtime_dont_use_autosuspend() during teardown, this reference is not dropped. The documentation for pm_runtime_use_autosuspend() also notes that it is important to undo it with pm_runtime_dont_use_autosuspend() at driver exit time, unless runtime PM was initially enabled with devm_pm_runtime_enable(). Add the missing pm_runtime_dont_use_autosuspend() call to the driver remove path. This issue was found by manual code inspection. Fixes: 6912aaf3fd24 ("HID: intel-thc-hid: intel-quickspi: Add PM implementation") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Reviewed-by: Even Xu <even.xu@intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-14HID: intel-thc-hid: intel-quicki2c: fix autosuspend cleanup during teardownGuangshuo Li
quicki2c_probe() calls pm_runtime_use_autosuspend(), but quicki2c_remove() does not call the matching pm_runtime_dont_use_autosuspend() during teardown. If the autosuspend delay is set to a negative value while autosuspend is enabled, the runtime PM core increments usage_count to prevent runtime suspend. Without calling pm_runtime_dont_use_autosuspend() during teardown, this reference is not dropped. The documentation for pm_runtime_use_autosuspend() also notes that it is important to undo it with pm_runtime_dont_use_autosuspend() at driver exit time, unless runtime PM was initially enabled with devm_pm_runtime_enable(). Add the missing pm_runtime_dont_use_autosuspend() call to the driver remove path. This issue was found by manual code inspection. Fixes: 5f420e8215c6 ("HID: intel-thc-hid: intel-quicki2c: Add PM implementation") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Reviewed-by: Even Xu <even.xu@intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-14HID: steam: Zero out inputs when disabling gamepad modeVicki Pfau
When gamepad mode is disabled the gamepad input devices will stop receiving updates. However, in the case where there are buttons still pressed this will appear as an indefinitely-held button. Instead we should zero out the inputs to make it look like things are all released. We do the same thing for gyroscope inputs to make sure it doesn't look like it's endlessly rotating, but we freeze the accelerometer input since zero isn't a neutral input on the surface of the Earth. Signed-off-by: Vicki Pfau <vi@endrift.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-14HID: steam: Clean up lockingVicki Pfau
This cleans up several issues with locking behavior, including RCU accesses not being guarded behind a lock. Signed-off-by: Vicki Pfau <vi@endrift.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-14HID: steam: Don't set feature reports when disconnectingVicki Pfau
When an input device is closed, we set a feature report to reset lizard mode and IMU mode. However, if the input device is closed because it was removed, then we will necessarily error out when sending this, resulting in logged errors. Since an error here is expected, we should just fail silently. Signed-off-by: Vicki Pfau <vi@endrift.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-14HID: steam: Fix wording of connect/disconnect logsVicki Pfau
It always said Controller, even on Deck. Since we special-case other instances of Controller vs. Deck in strings, let's be consistent here too. Signed-off-by: Vicki Pfau <vi@endrift.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-14HID: steam: Initial 2026 Steam Controller supportVicki Pfau
This brings support for the 2026 Steam Controller, comparably featureful to the existing support for the Steam Deck. Signed-off-by: Vicki Pfau <vi@endrift.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-14HID: steam: Refactor registrationVicki Pfau
This refactors and simplifies the registration/unregistration flow. Since we now only perform registration when the client isn't opened anymore, the logic for handling that can be removed, and the rest of the function streamlined. We also remove the previous assumption that we have a serial number to show we're registered, replacing it with a single purpose boolean. In a previous refactor the code for unregistering a battery if later registration steps failed was accidentally left out. As a result, a lingering power_supply object could get left over after the steam object was torn down. This is also fixed here. Signed-off-by: Vicki Pfau <vi@endrift.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-14HID: logitech: add Bolt receiver support for Logitech HID++ devicesErik Håkansson
Add Logitech Bolt receiver support to the Logitech HID receiver and HID++ drivers. Handle Bolt receiver notifications in hid-logitech-dj and add a Bolt-specific initialization path in hid-logitech-hidpp, separate from the existing Unifying receiver path. This allows Bolt-connected HID++ devices to expose battery information through the kernel power_supply path, so userspace tools can report their battery status with the correct device model. Also, treat HIDPP_ERROR_CONNECT_FAIL like other disconnected-device errors when retrieving protocol version to avoid protocol error messages when a Bolt device powers off. Tested with: - Logitech MX Keys for Business via Bolt receiver Signed-off-by: Erik Håkansson <erikhakan@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-14HID: sensor-hub: Fix out-of-bounds write in sensor_hub_get_featureXingrui Li
sensor_hub_get_feature() clamps its return value to the caller's buffer size, but the copy loop still copies field->report_size / 8 bytes for each report value. A malicious HID descriptor can advertise a large feature field size while an IIO caller supplies a small stack buffer, such as a single s32, causing an out-of-bounds write. HID core stores parsed report values in __s32 slots and clamps extracted values to 32 bits. Reject feature fields that require more than one slot per value, guard the total byte count calculation, and clamp each per-value copy to the remaining caller buffer. Fixes: 5459ada2b3cd69 ("HID: sensor-hub: Fix packing of result buffer for feature report") Cc: stable@kernel.org Assisted-by: OpenAI:GPT-5.5-Cyber Signed-off-by: Xingrui Li <baka9@bakabaka9.tech> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-14ASoC: cs35l56: Switch to using the IRQ from the SoundWire coreMark Brown
Richard Fitzgerald <rf@opensource.cirrus.com> says: At the time the cs35l56 driver was written the only way to get interrupts from the SoundWire core was to implement a custom handler inside the interrupt_callback() function. The SoundWire core now provides a virtual IRQ for notifying ImpDef interrupts, and switching to this simplifies the code and also makes it more similar to the normal interrupt handling of I2C/SPI (though some SoundWire specials are still needed). Patches #1 and #2 do some preparatory code shuffling so that there is less clutter in patch #4. Patch #3 changes the SoundWire core code to create the virtual ImpDef IRQ before calling the codec drive probe() so that the IRQ can be requested in probe(). Link: https://patch.msgid.link/20260810104045.60701-1-rf@opensource.cirrus.com
2026-08-14ASoC: cs35l56: Use IRQ provided by the SoundWire coreRichard Fitzgerald
Replace the custom SoundWire IRQ handling with the generic nested IRQ provided by the SoundWire core. This removes the local IRQ work function and the convoluted IRQ masking and pm_runtime management around it. We still need the local functions to mask/disable and unmask/enable the SoundWire interrupts because the devices handled by the cs35l56 driver don't have the generic mask bit for the ImpDef1 interrupt so masking and unmasking has to use a custom mask bit. cs35l56_sdw_remove() doesn't need to call cs35l56_disable_sdw_interrupts() now that there isn't a local work function to be flushed. It only masks the custom interrupt mask bit and the rest of the handler cleanup will be done the normal way by devm_free_irq() in cs35l56_remove(). Similar applies to cs35l56_sdw_system_suspend() - it is enough to write the custom mask bits. cs35l56_irq() doesn't need to be exported because cs35l56_sdw.c isn't calling it. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20260810104045.60701-5-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-14soundwire: bus_type: Create IRQ mapping before calling driver probe()Richard Fitzgerald
Call sdw_irq_create_mapping() before calling the peripheral driver probe() so that it is possible to request the IRQ during probe(). Previously creation of the mapping was conditional on the use_domain_irq flag in the driver properties. But these are filled in after probe(), which meant it wasn't possible to request the IRQ during probe(). This was ok for MFD drivers where only children requested the IRQ. But for normal drivers it led to the non-standard behavior of having to defer requesting the IRQ until after probe(). Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Acked-by: Vinod Koul <vkoul@kernel.org> Link: https://patch.msgid.link/20260810104045.60701-4-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-14ASoC: cs35l56: Move cs35l56_irq_request() after cs35l56_irq()Richard Fitzgerald
cs35l56_irq_request() references cs35l56_irq() but was above it in the source (although they are in the other order in the header file). Switch to convertional C ordering. This is preparation for a future patch that will stop exporting cs35l56_irq() and make it static. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20260810104045.60701-3-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-14ASoC: cs35l56: Request IRQ in cs35l56_common_probe()Richard Fitzgerald
Call cs35l56_irq_request() in cs35l56_common_probe() instead of calling it afterwards in the probe() for each bus type. Calling cs35l56_irq_request() in each bus probe() is a legacy of dealing with the oddities of the SoundWire framework. It's no longer serving any useful purpose to do it outside of the main cs35l56_common_probe(). Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20260810104045.60701-2-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-14spi: dt-bindings: sun6i: Add compatibles for A733's SPI controllersJerome Brunet
The A733 has six SPI controllers with the same IP as the A523. Like the A523, one of them (spi1) also supports DBI mode. Add SoC specific compatible strings, falling back to the A523 ones. Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Link: https://patch.msgid.link/20260812-allwinner-a733-spi-support-v2-1-937bff0fa78e@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-08-14HID: universal-pidff: stop the device when force-feedback init failsBaul Lee
universal_pidff_probe() starts the device with hid_hw_start() and then, if force-feedback initialisation fails, returns the error through a label that only does "return error". The device is left started. The HID core does not unwind on the driver's behalf. __hid_device_probe() releases the devres group, closes the report and clears hdev->driver: if (ret) { devres_release_group(&hdev->dev, hdev->devres_group_id); hid_close_report(hdev); hdev->driver = NULL; } The hidraw character device that hid_hw_start() registered through hid_connect() is allocated with kzalloc() and added with cdev_device_add(), so it is not devres-managed and survives that. With hdev->driver NULL, hid_device_remove() skips hid_hw_stop() as well, because it only unwinds while a driver is still attached. The registration therefore outlives the device on both paths. Opening the surviving /dev/hidrawX writes into freed memory. KASAN reports a use-after-free write from hidraw_open() -> hid_hw_open() -> the transport's open callback, which takes a spinlock inside the freed object. A descriptor that carries a PID usage page and no input reports is enough: hidraw claims the device so hid_hw_start() succeeds, while hid->inputs stays empty so force-feedback init fails. The other failure returns in hid_pidff_init_with_quirks() - no output reports, an allocation failure, pidff_init_fields(), pidff_check_autocenter(), an unusable effect count, input_ff_create() - all reach the same label. Stop the device on that path. hid-dr.c and hid-emsff.c, which start the device with the same HID_CONNECT_DEFAULT & ~HID_CONNECT_FF mask, already do this. The two earlier gotos must keep returning without hid_hw_stop(), since neither has a started device, so give the path that fails after the start its own label. Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com> Fixes: f06bf8d94fff ("HID: Add hid-universal-pidff driver and supported device ids") Cc: stable@vger.kernel.org Signed-off-by: Baul Lee <baul.lee@xbow.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-14HID: haptic: move FF initialization into .input_configured()Dmitry Torokhov
Refactor hid_haptic_init() to take a direct pointer to input_dev and integrate its invocation into hid_haptic_input_configured(). Update hid-multitouch to rely on the refactored callback to perform the force-feedback initialization during the registration loop. This ensures that force-feedback capabilities are set up before the input device is registered and exposed to userspace, closing the registration race. Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-14HID: logitech-hidpp: move FF initialization to .input_configured()Dmitry Torokhov
The driver currently initializes force-feedback in its probe() function after calling hid_connect(). This is racy as the input device is already registered and visible to userspace at that point. Move the FF initialization to the .input_configured() callback to ensure the device is fully prepared before registration. Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-14HID: megaworld: move FF initialization to .input_configured()Dmitry Torokhov
The driver currently initializes force-feedback in its probe() function after calling hid_hw_start(). This is racy as the input device is already registered and visible to userspace at that point. Move the FF initialization to the .input_configured() callback to ensure the device is fully prepared before registration. Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-14HID: smartjoyplus: move FF initialization to .input_configured()Dmitry Torokhov
The driver currently initializes force-feedback in its probe() function after calling hid_hw_start(). This is racy as the input device is already registered and visible to userspace at that point. Move the FF initialization to the .input_configured() callback to ensure the device is fully prepared before registration. Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-14HID: mayflash: move FF initialization to .input_configured()Dmitry Torokhov
The driver currently initializes force-feedback in its probe() function after calling hid_hw_start(). This is racy as the input device is already registered and visible to userspace at that point. Move the FF initialization to the .input_configured() callback to ensure the device is fully prepared before registration. Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2026-08-14HID: zeroplus: move FF initialization to .input_configured()Dmitry Torokhov
The driver currently initializes force-feedback in its probe() function after calling hid_hw_start(). This is racy as the input device is already registered and visible to userspace at that point. Move the FF initialization to the .input_configured() callback to ensure the device is fully prepared before registration. Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>